# Allow Customizable 404 Messages via msg Parameter in get\_object\_or\_404()

**URL:** <https://forum.djangoproject.com/t/allow-customizable-404-messages-via-msg-parameter-in-get-object-or-404/40442>\
**Category:** Accessibility\
**Created:** [April 16, 2025, 7:53am UTC](https://forum.djangoproject.com/t/allow-customizable-404-messages-via-msg-parameter-in-get-object-or-404/40442 "2025-04-16T07:53:05Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![PhenixDhinesh](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/phenixdhinesh/32/28113_2.png) [@PhenixDhinesh](https://forum.djangoproject.com/u/PhenixDhinesh)\
**Post date:** [April 16, 2025, 7:53am UTC](https://forum.djangoproject.com/t/allow-customizable-404-messages-via-msg-parameter-in-get-object-or-404/40442/1 "2025-04-16T07:53:05Z")

</div>

### **Summary (Description)**:

Currently, `django.shortcuts.get_object_or_404()` raises a hardcoded 404 message when an object is not found. Customizing this message requires wrapping it in a `try/except`, which adds unnecessary repetition and breaks the DRY principle.

### **Proposal** :

Introduce an optional `msg` parameter to `get_object_or_404()`, allowing custom 404 messages:

```python
obj = get_object_or_404(MyModel, pk=some_id, msg="Custom not found message")

```

This change would:

- Enable custom error messages without needing `try/except` blocks.
- Be backwards-compatible, defaulting to the current behavior if `msg` is not provided.
- Align with Django’s other customizable exceptions (e.g., `ValidationError`, `PermissionDenied`).

### **Justification** :

- Reduces repetitive code in views and APIs.
- Enhances flexibility for more meaningful 404 messages.
- Keeps Django’s philosophy of offering customizable error handling.

### **Request for Community Feedback** :

Would love to hear thoughts from the community on whether this change would be useful, or if there are other considerations we should take into account before moving forward with a PR.

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [April 16, 2025, 12:28pm UTC](https://forum.djangoproject.com/t/allow-customizable-404-messages-via-msg-parameter-in-get-object-or-404/40442/2 "2025-04-16T12:28:00Z")

</div>

Welcome @PhenixDhinesh !

The first issue you’re going to face is the possibility that _whatever_ keyword you try to use for the parameter _could_ conflict with a parameter that needs to be passed through to the query being executed. (What if someone has a model with a field named `msg`?)

If you’re really going to find this helpful, you can always create your own version of the function and call _it_ instead of the Django-provided function. Your function can either call the Django function or implement the base functionality itself - depending upon how you want to handle your extensions.

---

<div class="post-metadata">

**Author:** ![PhenixDhinesh](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/phenixdhinesh/32/28113_2.png) [@PhenixDhinesh](https://forum.djangoproject.com/u/PhenixDhinesh)\
**Post date:** [April 16, 2025, 1:04pm UTC](https://forum.djangoproject.com/t/allow-customizable-404-messages-via-msg-parameter-in-get-object-or-404/40442/3 "2025-04-16T13:04:14Z")

</div>

Fair Point. i haven’t though about it. thank for pointing out

---

<div class="post-metadata">

**Author:** ![ChathuraGH](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/chathuragh/32/27563_2.png) [@ChathuraGH](https://forum.djangoproject.com/u/ChathuraGH)\
**Post date:** [April 17, 2025, 4:27pm UTC](https://forum.djangoproject.com/t/allow-customizable-404-messages-via-msg-parameter-in-get-object-or-404/40442/4 "2025-04-17T16:27:31Z")

</div>

> [@KenWhitesell](#):
>
> What if someone has a model with a field named

We can use a name safe uuid(with a favorable name) if we really want. Just suggesting.