|Version 9 (modified by adrian, 10 years ago) (diff)|
Better Error Messages
This page is a place to collect error messages that could stand improvement, or which are misleading or confusing in certain contexts. Most of us have had the experience of getting a "weird" message, puzzling it out (perhaps with help from django-users or #django) and then moving on. Later it can be hard to remember what the problem was.
This is an experiment to see if having a dedicated place to describe these cases as we encounter them can help organize a quality-control effort. Good error messages make for more productive developers. (And it helps newbies be more self-supporting, too.)
Some of these may seem like quick patches but others will take a bit of consideration -- that's why the wiki page rather than individual tickets. Some are more along the lines of "Django Lint" than simple changes to error output.
For now, let's try dividing them into sections by major module. Within those sections suggested format is: error message, explanatory context (often important -- a message that is very helpful in one context can be confusing in another), suggested improvements/changes.
OperationalError: Unable to close due to unfinalised statements
Context: SQLite file permissions are incorrect (directory or DB file lack write permission)
Suggestion: Check file permissions when running with SQLite backend and warn user if they seem incorrect
'NoneType' object has no attribute 'get_field_sets'
Context: One or more models that are referenced by ForeignKey from another model are missing their inner Admin class. Possible other causes as well. See ticket #1808.
Suggestion: Check relevant Admin settings during model validation?
- Ticket #1732 -- a problem that elicits no error message, but should.
EnvironmentError: Could not import settings 'foo.settings' (Is it on sys.path? Does it have syntax errors?): No module named settings
Context: Application name is same as project name, causing import problems. (See #1908 for full example.)
Suggestion: Given how often beginners are likely to make this mistake, it would be nice for Django to look for this conflict and warn the user.
- Ticket #1791 suggests better error messages in cases where application dependencies are not satisfied.
- See this thread on the django-developers list for discussion of error suppression in the template engine