Yeah... not sure, though thank you for actually reading and responding
to my post.
"I think the problem you are having is more related to mod_wsgi, and
possible differences between it and mod_python, than Django."
Absolutely. Though, I'm not sure if it's the official recommendation
of django-project.com now or not, but most people in the community are
using mod_wsgi in Daemon mode. It is definitely a result of this,
also I doubt mod_wsgi is going to be changing the nature of their
exception handling code faster than you guys can keep up. It seems
like a pretty sweet setup right now so hopefully they don't change it
;)
Where django pulls a 500 it should call these two lines, which will
dump the exception raised to stderr.
type, value, traceback = sys.exc_info()
sys.excepthook(type, value, traceback)
If you have a logger setup, which I assume most sane people in
production do (right?!?). You can pass the exception info to the
logger with and have the same result as one that passes straight to
stderr only you can have more explicit control over how it behaves,
especially if django uses named loggers:
logger.error("This can't be good", exc_info=True)
We don't really need both, but either one should exist in django if
it's going to support wsgi ;) Perhaps, I'm missing some config
setting available to mod_wsgi that will replicate mod_python's
behavior in this regard, but i "feel" django should work with a
default setup.
Also, I've tested this on both Fedora 8, and mod_wsgi 2.x ... and the
latest 2.6.5 python + wsgi 3.2.
"http://docs.djangoproject.com/en/dev/howto/error-reporting/";
I can't use email reporting because of performance, logistics, and
sheer volume in production.
-k
On Wed, May 5, 2010 at 1:51 PM, Karen Tracey <kmtra...@gmail.com> wrote:
> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton <kevin.hower...@gmail.com>
> wrote:
>>
>> What I was suggesting in my post though, was that we alter the default
>> CRITICAL error handling behavior ... as it stands (by default) all of
>> my ERRORs are being suppressed in production. This is pretty
>> confusing for new users (there were 3 others in IRC with the same
>> complaint yesterday), and pretty un-pythonic IMO. Unless I missed
>> something?
>
> I think you are missing something. From your earlier note you seem to be
> saying that it is information your own code is writing to stderr that is
> getting lost somewhere. Django does nothing to suppress anything sent do
> stderr. I've got views that write to stderr running under mod_wsgi, and the
> stderr output appears in the configured Apache error log. You do need to
> either include a newline in the data or explicitly flush stderr for the data
> to be written, and that may be a difference from mod_python (I don't
> remember enough about mod_python to say one way or the other). I think the
> problem you are having is more related to mod_wsgi, and possible differences
> between it and mod_python, than Django.
>
>>
>> At minimum the documentation should inform the user of this
>> short-coming, and provide a link to a wiki with the available
>> work-arounds.
>
> It isn't clear to me what shortcoming you think should be documented. If it
> is the behavior of mod_wsgi with respect to stderr possibly the deployment
> docs for mod_wsgi could mention something, but one danger of Django putting
> information like this in the docs is that it gets out of date as mod_wsgi
> evolves. In general it seems better to provide a minimum amount of
> information in Django doc, stuff that is specific to Django, and point the
> user to the appropriate source for authoritative documentation on the
> 3rd-party package.
>
> For the record, Django's default handling of critical errors when DEBUG is
> False is fully documented:
>
> http://docs.djangoproject.com/en/dev/howto/error-reporting/
>
> Karen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
