On Thursday 07 January 2010 01:35:50 Russell Keith-Magee wrote: > From a cursory inspection, I'm not sure there is much we can do with > (1) - there isn't a lot of detail on Exception that can be used for a > capability check, and the only attribute that is actually needed is > 'source' (albeit in a particular format that evidently Jinja doesn't > use).
Agreed, that is why the patch in the referenced ticket was denied. http://code.djangoproject.com/attachment/ticket/10216/10216.diff > (2) isn't Django's problem to fix. If it would just be a problem with Jinja than I would agree. However, Django breaks on every Exception with a source attribute that doesn't follow the Django style completely. > (3) Seems like the most promising option. For example, most of the > call to ExceptionReporter .get_template_exception_info() could be > deferred to the exception itself. If we refactored that code into a > method on the exception itself, we could use that method as the > capability that we check for. It would be less ambiguous (not many > exceptions would have a 'get_template_exception_info' method), and it > would allow *any* exception (template or otherwise) to raise an > embedded exception that provided template details on the technical 500 > page. Agreed, that would probably be the best solution. Although I do think that duck typing for catching exceptions is generally not the way to go. Exceptions should always be caught explicitly > However, as I said originally - the existing setup works for Django at > present. If you want to improve support for Jinja... patches are > accepted :-) As soon as I get back to the latest trunk release (I'm currently working on a revision that's about a year old) I will write a patch for this problem. Patching the old release and merging it with the current changes looks like it is going to be quite a tedious process. ~Rick
signature.asc
Description: This is a digitally signed message part.
