On Wed, May 5, 2010 at 1:53 PM, Kevin Howerton <kevin.hower...@gmail.com> wrote: > 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)
No, really it shouldn't. I made a quick scan of sites I maintain (or help maintain) in production now. Among them: - 3 use the built-in errors over email (and this works fine). - 1 logs exceptions to a local syslog daemon. - 2 log to a remote syslogd server (one via TCP, the other via UDP). - 2 log to stderr (and hence to the apache error log) - 1 logs to stdout (<-- that's probably a bug :) This all works *right now* without any changes to Django. Further, your suggested change would break at least a couple of them. Look, Django's got a *LOT* of ways to customize error handling and logging. - Use the logging package directly where needed. - Write a piece exception middleware. - Subclass the handler (either ModPythonHandler or WSGIHandler) and override exception handling. - Write a WSGI exception middleware. We're not going to add yet-another-extension-point unless you can point to a very good reason for it, and you haven't yet. Jacob -- 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.
