Traceback in the ``runserver`` console
Fridrik Mar Jonsson
I recently had an instance where it would have been really convenient
to see the error and a traceback in the ``runserver`` console instead
of just a single line telling me that the request returned a 500
error.
In the event of blind debugging, where a 3rd party tool is performing
a request that renders in an error, is there a Django mechanism or
extension that allows you to catch any exceptions that occur during a
page load and redirect them to the ``runserver`` console in addition
to displaying them in the template?
For an optimistic moment I thought ``--traceback`` was a bit
promising, but then it turned out that it doesn't really seem to do
what I expected in the case of ``runserver``. I even considered
switching to e-mail tracebacks but ended up writing a client to mimic
the 3rd party tool's functionality instead.
Your insights are appreciated.
Regards,
Friðrik Már
Russell Keith-Magee
>
> Hi Djangonians,
>
> I recently had an instance where it would have been really convenient
> to see the error and a traceback in the ``runserver`` console instead
> of just a single line telling me that the request returned a 500
> error.
>
> In the event of blind debugging, where a 3rd party tool is performing
> a request that renders in an error, is there a Django mechanism or
> extension that allows you to catch any exceptions that occur during a
> page load and redirect them to the ``runserver`` console in addition
> to displaying them in the template?
There are two options I can think of on an unmodified Django install.
Firstly, write a middleware that implements process_exception(). This
middleware will get invoked whenever an exception is raised as part of
the view; the middleware method will be the exception as one of the
arguments.
http://docs.djangoproject.com/en/dev/topics/http/middleware/#process-exception
Secondly, write a listener for the got_request_exception signal. This
signal is fired whenever an exception other than 404, Permission
Denied, or SystemExit is raised.
http://docs.djangoproject.com/en/dev/ref/signals/#django.core.signals.got_request_exception
> For an optimistic moment I thought ``--traceback`` was a bit
> promising, but then it turned out that it doesn't really seem to do
> what I expected in the case of ``runserver``. I even considered
> switching to e-mail tracebacks but ended up writing a client to mimic
> the 3rd party tool's functionality instead.
When I read this I went and had a look at the code, and it appears you
are correct. ``--traceback`` exists as a top-level command option, but
it doesn't appear to be exploited at all in runserver. This actually
surprised me - it seems like a reasonable suggestion for an
improvement. Feel free to open this as a ticket (and if you're really
adventurous, work on a patch :-)
Yours,
Russ Magee %-)
Fridrik Mar Jonsson
As I thank you for your quick reply I apologise for my lack thereof.
These approaches seem well suited (and surprisingly clean) for
achieving the desired functionality. I think it will make sense to
suggest an improvement to the `--traceback` switch, perhaps making a
patch if I have a brave moment sometime soon, and I appreciate the
encouragement.
Regards,
Friðrik Már
On Dec 27 2008, 1:14 pm, "Russell Keith-Magee"
<freakboy3...@gmail.com> wrote:
>
>
>
> > Hi Djangonians,
>
> > I recently had an instance where it would have been really convenient
> > to see the error and a traceback in the ``runserver`` console instead
> > of just a single line telling me that the request returned a 500
> > error.
>
> > In the event of blind debugging, where a 3rd party tool is performing
> > a request that renders in an error, is there a Django mechanism or
> > extension that allows you to catch any exceptions that occur during a
> > page load and redirect them to the ``runserver`` console in addition
> > to displaying them in the template?
>
> There are two options I can think of on an unmodified Django install.
>
> Firstly, write a middleware that implements process_exception(). This
> middleware will get invoked whenever an exception is raised as part of
> the view; the middleware method will be the exception as one of the
> arguments.
>
> Secondly, write a listener for the got_request_exception signal. This
> signal is fired whenever an exception other than 404, Permission
> Denied, or SystemExit is raised.
>
Simon Forman
<freakboy3...@gmail.com> wrote:
>
>
>
> > Hi Djangonians,
>
> > I recently had an instance where it would have been really convenient
> > to see the error and a traceback in the ``runserver`` console instead
> > of just a single line telling me that the request returned a 500
> > error.
manage.py runserver" stops printing out tracebacks. The "--traceback"
and "-v" options do nothing.
> > In the event of blind debugging, where a 3rd party tool is performing
> > a request that renders in an error, is there a Django mechanism or
> > extension that allows you to catch any exceptions that occur during a
> > page load and redirect them to the ``runserver`` console in addition
> > to displaying them in the template?
>
> There are two options I can think of on an unmodified Django install.
>
> Firstly, write a middleware that implements process_exception(). This
> middleware will get invoked whenever an exception is raised as part of
> the view; the middleware method will be the exception as one of the
> arguments.
>
> Secondly, write a listener for the got_request_exception signal. This
> signal is fired whenever an exception other than 404, Permission
> Denied, or SystemExit is raised.
>
> > For an optimistic moment I thought ``--traceback`` was a bit
> > promising, but then it turned out that it doesn't really seem to do
> > what I expected in the case of ``runserver``. I even considered
> > switching to e-mail tracebacks but ended up writing a client to mimic
> > the 3rd party tool's functionality instead.
>
> When I read this I went and had a look at the code, and it appears you
> are correct. ``--traceback`` exists as a top-level command option, but
> improvement. Feel free to open this as a ticket (and if you're really
> adventurous, work on a patch :-)
>
> Yours,
> Russ Magee %-)
I'm curious.
Regards,
~Simon
Russell Keith-Magee
>
> On Dec 27 2008, 5:14 am, "Russell Keith-Magee"
> <freakboy3...@gmail.com> wrote:
>> On Sat, Dec 27, 2008 at 2:32 AM, Fridrik Mar Jonsson <fridr...@gmail.com> wrote:
>>
>> > I recently had an instance where it would have been really convenient
>> > to see the error and a traceback in the ``runserver`` console instead
>> > of just a single line telling me that the request returned a 500
>> > error.
>
> I just noticed this too. Sometime between 0.96.3 and 1.0 "./
> manage.py runserver" stops printing out tracebacks. The "--traceback"
> and "-v" options do nothing.
This isn't entirely surprising. Between 0.96 and 1.0, manage.py
received a major refactor. Unfortunately, the command line behavior of
django-admin is one of those things that is very difficult to unit
test, so it is quite easy for mistakes like this to slip in
accidentally.
If you're particularly enthused by the historical reasoning, you could
search the Subversion history to find the revision at which the
feature disappeared. 0.96 was tagged at r4810, so anywhere between
there and now (r9772 as I write this) could be the cause. With a
binary search, you should be able to find the offending revision in
about a dozen steps.
>> > For an optimistic moment I thought ``--traceback`` was a bit
>> > promising, but then it turned out that it doesn't really seem to do
>> > what I expected in the case of ``runserver``. I even considered
>> > switching to e-mail tracebacks but ended up writing a client to mimic
>> > the 3rd party tool's functionality instead.
>>
>> When I read this I went and had a look at the code, and it appears you
>> are correct. ``--traceback`` exists as a top-level command option, but
>> it doesn't appear to be exploited at all inrunserver. This actually
>> surprised me - it seems like a reasonable suggestion for an
>> improvement. Feel free to open this as a ticket (and if you're really
>> adventurous, work on a patch :-)
>
> I can open a ticket, and even attempt a patch. How did this go away?
> I'm curious.
Magic elves. They conspired with the fairies :-)
Seriously, I have no idea. I can't think of any reason it would be
deliberate. Regardless of the cause, it would be nice to have this
feature restored. Any patch would be gratefully accepted.
Yours
Russ Magee %-)
rz
ticket and/or started working on a patch?