I'm the author of the current patch; I'll just add a bit of background. On Dec 12, 10:18 pm, ab <andrewb...@gmail.com> wrote: > > 1. Scope -- the patch generalizes the issue and addresses it > throughout Django. Are people ok with that?
Since the problem of raising new exceptions and losing the original one seemed systemic throughout much of Django, I thought it appropriate to make the patch address all known instances of this class of problem, and not just the one instance in the original complaint. > 2. Design -- The wrap_and_raise function needs to be used not only at > the site of the problem, but also possibly at a deeper level in the > call stack as well. In this particular case, it needs to be used in > both `get_library` and `load` to address the original issue. Correct. It needs to be used wherever Django is catching an exception arising from user-supplied code and then raising a different exception. > 3. Design -- Seeing the ImportError's traceback is indeed helpful in > identifying the source of the problem. But, it's also kind of weird to > have the traceback of an ImportError (ending with the line "import > notthere" or whatever) associated with a different exception. I'll just clarify for anyone that hasn't applied the patch and tried it: with the patch in place, the traceback will still show down to the TemplateSyntaxError, but instead of stopping there will also continue down to where the ImportError originated. Yes, it's a little weird; Python 3.0 handles this whole situation much better with "raise ... from ..." which is intended for use in precisely these situations. Andrew -- 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.
