How do I get tracebacks printed to terminal?

614 views
Skip to first unread message

Markus Barth

unread,
Nov 23, 2010, 3:48:42 PM11/23/10
to Django users
I am using quite a lot of asynchronous calls for updating a page. The
problem is that this way you never see a traceback. In turbogears the
development server prints all tracebacks to the terminal. Is there any
way to get a similar behaviour with django?

Javier Guerra Giraldez

unread,
Nov 23, 2010, 5:19:51 PM11/23/10
to django...@googlegroups.com

firebug can show the content of any request/response, including AJAX
ones. it also renders any HTML content, like those generated by the
Django error pages

--
Javier

Markus Barth

unread,
Nov 23, 2010, 5:23:29 PM11/23/10
to Django users
I have just found a post from beginning of last year pointing out that
this feature got "lost" during the transition from 0.9 to 1.0. I have
digged a bit through the code but must admit that fixing this
definitely should be done by someone who is familiar with django
internals.

Tracebacks are one of the strongest features of python and without
them the slogan that Django is for "perfectionists with deadlines" is
not applicable in case of ajax/json apps - because you spend more time
trying to blindly find your bug than actually developping.

Markus Barth

unread,
Nov 23, 2010, 5:33:10 PM11/23/10
to Django users


On 23 nov, 23:19, Javier Guerra Giraldez <jav...@guerrag.com> wrote:
> On Tue, Nov 23, 2010 at 3:48 PM, Markus Barth
>
> <naturalparkdelseg...@gmail.com> wrote:
> > I am using quite a lot of asynchronous calls for updating a page. The
> > problem is that this way you never see a traceback. In turbogears the
> > development server prints all tracebacks to the terminal. Is there any
> > way to get a similar behaviour with django?
>
> firebug can show the content of any request/response, including AJAX
> ones.  it also renders any HTML content, like those generated by the
> Django error pages
>
> --
> Javier

This is only helpful if the request is answerered by the server, but
as soon as you have an exception, all you see on the console is a 500
Error and Firebug tells you "status: aborted"

For example I have just spend an hour chasing a bug just to find out
that syncdb didn't sync a table. With a traceback I would have seen
the problem within seconds

Anyway, thanks for the hint

Markus Barth

unread,
Nov 23, 2010, 5:39:52 PM11/23/10
to Django users
Sorry, I have to correct myself, in fact, I got the information
through firebug. Thanks a lot, that saved my day.

Reinout van Rees

unread,
Nov 24, 2010, 7:48:15 AM11/24/10
to django...@googlegroups.com

You'll have to enable that yourself with some middleware, strangely.

In your app/site, add a "middleware.py":


import logging

logger = logging.getLogger(__name__)


class TracebackLoggingMiddleware(object):
"""Middleware that logs exceptions.

See http://djangosnippets.org/snippets/421/.

To enable it, add
'yourapp.middleware.TracebackLoggingMiddleware' to
your setting.py's MIDDLEWARE_CLASSES.

"""

def process_exception(self, request, exception):
logger.exception(repr(request))

And do the MIDDLEWARE_CLASSES thingy in the docstring.

Reinout

--
Reinout van Rees - rei...@vanrees.org - http://reinout.vanrees.org
Collega's gezocht!
Django/python vacature in Utrecht: http://tinyurl.com/35v34f9

David De La Harpe Golden

unread,
Nov 24, 2010, 8:09:13 AM11/24/10
to django...@googlegroups.com

People have already mentioned firebug's ability to show the contents
of the error response. Note that you can also define an
exception middleware that will catch exceptions raised by your views
(but not all exceptions raised in the course of request-response
processing*) occuring during request processing and then you can e.g.
format the error into a json response, say, for less pain on the client
side.

*
(i) the obvious - an apache level error, not all that much django can do
there
(ii) Some exceptions, mostly those raised by the resolver, escape the
exception middleware, just owing to the structure of the code, see
BaseHandler.get_response() [2]. Subclassing the Handler seems to be the
least worst way to deal with that right now.

[2]
http://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py

Reply all
Reply to author
Forward
0 new messages