> 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 not saying that writing a subclass in Python is a high barrier to entry. I'm saying that the handler in particular is hard to subclass. And I agree that subclassing it would be 'the perfect way', if only it didn't require a configuration change (yes, only once, but that is once more than required by basically any other change to a Django app) and didn't introduce differences between the test and release environments. I mean, really, the notification method for errors should have nothing to do with the type of web server interface you have (WSGI / mod_python). It's just an artifact of the way the code is currently factored. > Patches welcome to fix that if you see it as a real problem. I suppose the easiest way is to patch mail_admins to not attempt to send email if ADMINS is empty. On Oct 16, 2:41 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > 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'd like, though. For > > one, this kind of customization requires updating the apache > > configuration file to point to the new handler. It's annoying to have > > to update Apache config files in synchronization with the Python app > > code. > > Well, not really. You have to set the Apache configuration once to point > to the right thing. Just like you do now. > > > Also, I suspect that a large number of Django developers use > > "manage.py runserver" (which is hardcoded to use WSGIHandler) for > > development and testing and use ModPythonHandler on the release > > servers. To minimize unexpected bugs in the release environment that > > never show up in the test environment, it's best not to introduce > > additional differences between these environments. A custom > > implementation of handle_uncaught_exception would be hard for a > > developer using "manage.py runserver" to test. > > Patches welcome to fix that if you see it as a real problem. > > > My hunch is that even though there isn't a common way that users would > > want to customize uncaught exceptions, it's probably common that users > > would want to customize it in some way or another. So subclassing the > > handler seems like a rather high barrier to entry. > > > I don't see any of your objections here a real issues except the need > for being able to simulate things in the development server. > > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
