Re: Customizing notification method for internal server errors

2008-10-16 Thread Jesse Young
The --with-handler idea for manage.py runserver sounds reasonable to me. I just wanted to clarify a couple of points. > No, this isn't correct. You already have to specify which handler to > run. You still have to do that exactly once in each case. I meant that it requires one extra configurati

Re: Customizing notification method for internal server errors

2008-10-16 Thread Malcolm Tredinnick
On Thu, 2008-10-16 at 15:15 -0700, Jesse Young wrote: > > No it's not. Since there's no common way to customize, sub-classing is > > the perfect way to do it, since people can then do whatever they want. > > How is asking somebody to write a subclass in Python a high barrier to > > entry? We're a

Re: Customizing notification method for internal server errors

2008-10-16 Thread Jesse Young
> No it's not. Since there's no common way to customize, sub-classing is > the perfect way to do it, since people can then do whatever they want. > How is asking somebody to write a subclass in Python a high barrier to > entry? We're assuming knowledge of the language, but that's all. Well, I'm n

Re: Customizing notification method for internal server errors

2008-10-16 Thread Malcolm Tredinnick
On Wed, 2008-10-15 at 18:59 -0700, Jesse Young wrote: > Hi Malcolm, > > Thanks for explaining the rationale behind this. It'd certainly be > possible to do what we want by overriding handle_uncaught_exception in > a ModPythonHandler subclass. > > This method has a higher barrier to entry than I

Re: Customizing notification method for internal server errors

2008-10-16 Thread oggie rob
On Oct 15, 10:18 pm, Jesse Young <[EMAIL PROTECTED]> wrote: > Is your suggestion that, since mail_admins happens to be the only > place in Django that uses settings.ADMINS, I could do something like: > > class AdminsObject(list): >    def __iter__(self): >      // do some custom notification >    

Re: Customizing notification method for internal server errors

2008-10-16 Thread Ivan Sagalaev
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 > desir

Re: Customizing notification method for internal server errors

2008-10-15 Thread Jesse Young
Is your suggestion that, since mail_admins happens to be the only place in Django that uses settings.ADMINS, I could do something like: class AdminsObject(list): def __iter__(self): // do some custom notification // manually write the friendly 500 error page to the output stream some

Re: Customizing notification method for internal server errors

2008-10-15 Thread oggie rob
Did you try subclassing list (& overriding __iter__) for the ADMINS object? -rob On Oct 15, 1:58 pm, Jesse Young <[EMAIL PROTECTED]> 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

Re: Customizing notification method for internal server errors

2008-10-15 Thread Jesse Young
Hi Malcolm, Thanks for explaining the rationale behind this. It'd certainly be possible to do what we want by overriding handle_uncaught_exception in a ModPythonHandler subclass. This method has a higher barrier to entry than I'd like, though. For one, this kind of customization requires updatin

Re: Customizing notification method for internal server errors

2008-10-15 Thread Malcolm Tredinnick
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 h

Re: Customizing notification method for internal server errors

2008-10-15 Thread Jeremy Dunck
On Wed, Oct 15, 2008 at 6:26 PM, Jesse Young <[EMAIL PROTECTED]> wrote: > > I see there is a got_request_exception signal already... so one could > effectively do the same thing by adding a signal handler and making > settings.ADMINS the empty list so that mail_admins effectively becomes > a no-op

Re: Customizing notification method for internal server errors

2008-10-15 Thread Jesse Young
I see there is a got_request_exception signal already... so one could effectively do the same thing by adding a signal handler and making settings.ADMINS the empty list so that mail_admins effectively becomes a no-op. Even so, it looks like mail_admins will open a SMTP connection to send an email

Re: Customizing notification method for internal server errors

2008-10-15 Thread Jeremy Dunck
On Wed, Oct 15, 2008 at 3:58 PM, Jesse Young <[EMAIL PROTECTED]> wrote: ... > I was thinking it would be useful to add a setting like > EXCEPTION_NOTIFIER = 'path.to.custom.notifier' , where the default > would look something like this: > > def mail_exception_to_admins(request, exc_info): >

Customizing notification method for internal server errors

2008-10-15 Thread Jesse Young
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... We worked around this by