Should exceptions in dev server appear as tracebacks in the console by default?

172 views
Skip to first unread message

Harry Percival

unread,
Dec 28, 2013, 8:11:00 AM12/28/13
to Django Developers group
The docs say:

"All messages reaching the django catch-all logger when DEBUG is True are sent to the console. They are simply discarded (sent to NullHandler) when DEBUG is False."

https://docs.djangoproject.com/en/1.6/topics/logging/#django-s-default-logging-configuration

From reading that, I would (naively?) expect to see tracebacks in the terminal I'm running manage.py runserver, if any of my views raise an exception for example. I don't see any, however.

Is this because the exception is caught, in that it gets intercepted and turned into the nice django debug page?  Am i misinterpreting the docs?  If so, would it be worth adding a couple of words of clarification in case anyone else might misread it like me?  Assuming anyone is that silly?

Of course, I would rather prefer it if exception tracebacks did go to the console by default, as well as to mail_admins and/or to a nice django debug page.  But maybe that's just me.

hp

PS minimal repro:

django-admin.py startproject myproj
python manage.py startapp myapp

urls.py:

from django.conf.urls import patterns, include, url
urlpatterns = patterns('',
    # Examples:
    url(r'^$', 'myapp.views.home', name='home'),
)

myapp/views.py:

def home(request):
    raise Exception('arg')

PPS apologies for x-post from django-users

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/tCw4bqw2tsI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/60d3c4c6-22f8-4de6-a376-6230c33ad0a9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
------------------------------
Harry J.W. Percival
------------------------------
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype:         harry.percival

Harry Percival

unread,
Jan 3, 2014, 10:44:00 AM1/3/14
to Tim Graham, Django Developers group
Thanks Tim, let me make sure I understand the current functionality:

- django.request is the logger for views (broadly speaking)  any logging "elsewhere" would go to logger "django" instead.
- django.request is set to propagate=False

- if DEBUG is False, an exception in a view would go to mail_admins, but *not* to the console, because propagate=False
- if DEBUG is False a logging.info outside of django.request would end up going nowhere anyway, because the console handler has require_debug_true

- if DEBUG is True, an exception in a view goes only into the rendered debug HTML message
- if DEBUG is True, a logging.info in a view goes nowhere, because propagate=False (a quick test confirms this, but i may have done it wrong?)
- if DEBUG is True, a logging.info outside of django.request would go to the console

So I have two questions:

1/ what is the scope of django.request?  Am I right in thinking it's "pretty much everything you normally do with django" because it's "any code that's invoked while handling a wsgi request" - so, in normal use, everything in views.py, forms.py, models.py etc....  the only obvious way i can think of not going through a request would be a management command?

2/ wouldn't it be better if, when DEBUG=True, more logging stuff ended up in the console?  logging for management commands going to stderr by default is great, but wouldn't it be cool if logging.info and logging.exception in a view also went to stderr?

Happy to update the docs if i can get answers up to 1/ at least :)


On 1 January 2014 20:46, Tim Graham <timog...@gmail.com> wrote:
I believe tracebacks are handled by the 'django.request' logger, not the 'django' logger.

You may find the commit that added that documentation and the related ticket helpful:
https://code.djangoproject.com/ticket/18993

Documentation improvements would be welcome if you feel they are appropriate.

Harry Percival

unread,
Jan 15, 2014, 12:48:15 PM1/15/14
to Tim Graham, Django Developers group
so, just to rephrase this, to help think about how the docs could be improved. If I understand things correctly:

with the default settings, the only circumstances in which a logging message would end up in the console is outside of normal django request handling, for example in a management command, and only if DEBUG is set to True.

Is that correct?

Tim Graham

unread,
Aug 12, 2014, 6:35:19 PM8/12/14
to django-d...@googlegroups.com, timog...@gmail.com, hj...@cantab.net
The docs say "django is the catch-all logger. No messages are posted directly to this logger." so I don't think any messages would appear in the console from there unless a user uses that logger directly. I don't think any additional logging besides the requests will appear in the console by default unless the user adds logging calls to the django logger (actually deprecation warnings will appear there too).

re: "- if DEBUG is True, an exception in a view goes only into the rendered debug HTML message"
The logging calls are still made, but mail_admins is the only default handler and it does nothing if DEBUG is True.

Let me know if you have more questions, although I think most of it can be answered by looking at the code.
Reply all
Reply to author
Forward
0 new messages