On Wed, 2008-10-15 at 13:58 -0700, Jesse Young wrote: > The built-in behavior for > django.core.handlers.base.handle_uncaught_exception calls mail_admins > for each internal server error. > > So if a very high-traffic view has an internal server error, duplicate > emails will be sent at a very high rate. This isn't usually > desirable...
So the reason handle_uncaught_exception is in its own method is, as noted in the docstring for that method, so that you can have exactly this type of control. I have one client, for example, who want to use Python's logging module instead of sending email and no doubt lots of other customisations are possible. The idea is that you create your own subclass of which django/core/handlers/* class you want (wsgi or modpython, typically) and override the handle_uncaught_exception method. After all, you specify the handler class to use when setting things up to talk to the webserver, so it's just as easy to use your own subclass as one of Django's built in versions. This is done via subclassing rather than a setting to avoid settings proliferation for something where there's no real common case of customisations and so the ultimate configuration is provided: you write Python code to do whatever you want. It's also meant to impose a slight barrier to entry in the sense that you have to be able to write Python code in order to customise this, which is reasonable for something as core-functionality oriented as handling uncaught exceptions (and no problems for people on django-dev, obviously). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
