#30752: Allow using ExceptionReporter subclass in
django.views.debug.technical_500_response
---------------------------------+---------------------------------------
Reporter: Carlton Gibson | Owner: Pavel Lysak
Type: New feature | Status: assigned
Component: Error reporting | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
---------------------------------+---------------------------------------
Changes (by Carlton Gibson):
* needs_docs: 0 => 1
Old description:
> #29714 allows using an ExceptionReporter subclass with AdminEmailHandler.
>
> Ideally we'd make the similar available for the 500 debug error view.
>
> [https://github.com/django/django/blob/52e9c753659ffeab67149fcf26b95c10cf137c40/django/views/debug.py#L84-L95
> Currently the use of `ExceptionReporter` is hardcoded.]
>
> * Move this to a parameter
> * Provide an example of using, e.g., `functools.partial` to configure a
> subclass when specifying `handler500`.
New description:
#29714 allows using an ExceptionReporter subclass with AdminEmailHandler.
Ideally we'd make the similar available for the 500 debug error view.
[https://github.com/django/django/blob/52e9c753659ffeab67149fcf26b95c10cf137c40/django/views/debug.py#L84-L95
Currently the use of `ExceptionReporter` is hardcoded.]
~~* Move this to a parameter~~
~~* Provide an example of using, e.g., `functools.partial` to configure a
subclass when specifying `handler500`.~~
**Updated** for [https://code.djangoproject.com/ticket/30752#comment:5
comment:5]
* Add `ExceptionReporter` to the documentation, explaining the relation
between the exception reporter class and the filter it uses, and showing a
simple override of `get_traceback_data()`.
* Add a `DEFAULT_EXCEPTION_REPORTER` setting to allow specifying this.
(At that point we could review deprecating
`DEFAULT_EXCEPTION_REPORTER_FILTER`, as was discussed on #25167 — but
maybe that's unnecessary. Thoughts?)
--
Comment:
Hi Pavel, thanks for your input.
You're absolutely correct re the `handler500` suggestion. That's not
sufficient at all. (I'm not sure quite what was in my head thinking about
this.)
I've adjusted the description appropriately.
Looking at it, there's no nice way to pass down the exception reporter
class so, I agree, a setting will be the easiest way forward.
Your PR looks more or less right, but I think we need to say more in the
`Custom error reports` section. Specifically we should probably begin
stating that the reports are created by the `ExceptionReporter` class, and
that it uses an `ExceptionReporterFilter` to control the filtering. Then
then existing filtering examples are OK — that's the first port of call ‚
before giving an override example for `ExceptionReporter`...
{{{
#!python
class CustomExceptionReporter(ExceptionReporter):
def get_traceback_data(self):
data = super().get_traceback_data()
# ... remove/add something here...
return data
}}}
That should be about it. (I'm not sure there's any demand to customise
anything else on `ExceptionReporter`.)
Thanks again, super stuff.
--
Ticket URL: <https://code.djangoproject.com/ticket/30752#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.807f9eb4d303ef63d7c92a1a0433b9fa%40djangoproject.com.
