(patch) Gracefully handling ImportErrors in user modules.
|Reported by:||FunnyMan3595||Owned by:||axiak|
|Cc:||mike@…, funnyman3595@…||Triage Stage:||Accepted|
|Has patch:||yes||Needs documentation:||yes|
|Needs tests:||yes||Patch needs improvement:||yes|
(This issue is filed against 1.0 because that's the version I have installed (1.0.2, specifically) and can confirm it with. Code inspection suggests that the problem still exists in SVN, and the attached patch applies to SVN successfully, albeit with some grumbling about the line numbers being wrong.)
Consider the following line of code, taken from a Django application's views.py file:
from django.contrib.models.auth import User
This represents a fairly common type of programmer error, a mistake in naming. In this case, I attempted to import models.auth instead of the correct auth.models. As expected, this generates an error which must be fixed.
If this error happens within a view function, Django will catch it and (if DEBUG is on) print a nice error message.
If, however, this error happens at the module level, Django fails to catch the error, and it becomes a generic 500 error. The exception falls through to the webserver's error logs instead of being instantly displayed to the programmer.
The reason for this distinction is that at the module level, any exception is transformed into an ImportError, making the module completely unavailable and propagating the exception instantly. This causes Django to fail before it has entered the usual error-catching mechanism.
The attached patch fixes this by wrapping the code which triggers the initial import in the same error-catching routines, and also alters the point of import so that the original ImportError may be displayed instead of the ViewDoesNotExist exception which Django raises in its stead.
This patch should be considered a proof-of-concept. It has not been polished beyond basic debugging, and may well be implemented at a suboptimal level of the initial traceback or written in a non-idiomatic fashion. It may also be worth searching for other places where a similar treatment is necessary, but this is beyond my current understanding of Django.
The patch does, however, solve my problem.
Change History (9)
comment:1 Changed 4 years ago by axiak
- Cc mike@… added
- Keywords exception handling added
- milestone set to 1.3
- Needs documentation set
- Needs tests set
- Owner changed from nobody to axiak
- Patch needs improvement set
- Status changed from new to assigned
- Triage Stage changed from Unreviewed to Design decision needed
- Version changed from 1.0 to SVN