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

[Tim Graham]

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.

On Wednesday, January 15, 2014 12:48:15 PM UTC-5, Harry Percival wrote:
>
> 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?
>
>
>
> On 3 January 2014 15:44, Harry Percival  > wrote:
>
>> 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  
>> 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://github.com/django/django/commit/f0f327bb
>>> https://code.djangoproject.com/ticket/18993
>>>
>>> Documentation improvements would be welcome if you feel they are 
>>> appropriate.
>>>
>>>
>>> On Saturday, December 28, 2013 8:11:00 AM UTC-5, Harry Percival wrote:
>>>
  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', 

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

[Harry Percival]

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?



On 3 January 2014 15:44, Harry Percival  wrote:

> 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  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://github.com/django/django/commit/f0f327bb
>> https://code.djangoproject.com/ticket/18993
>>
>> Documentation improvements would be welcome if you feel they are
>> appropriate.
>>
>>
>> On Saturday, December 28, 2013 8:11:00 AM UTC-5, Harry Percival wrote:
>>
>>>  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
>>> 

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

[Harry Percival]

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  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://github.com/django/django/commit/f0f327bb
> https://code.djangoproject.com/ticket/18993
>
> Documentation improvements would be welcome if you feel they are
> appropriate.
>
>
> On Saturday, December 28, 2013 8:11:00 AM UTC-5, Harry Percival wrote:
>
>>  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 J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to