|Version 6 (modified by 11 years ago) (diff),|
Better Error Messages
Better error messages make everybody work faster. I'm starting this page as 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 I know that others will take a bit of consideration -- that's why the wiki page rather than individual tickets.
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.
django.core.exceptions.ImproperlyConfigured: Could not load database backend: cannot import name connection. Is your DATABASE_ENGINE setting (currently, 'mysql') spelled correctly? Available options are: 'ado_mssql', 'dummy', 'mysql', 'postgresql', 'sqlite3'
Context: Encountered while hacking on the db backend, which means its possibly very obscure.
Suggestion: Django can determine whether the DATABASE_ENGINE setting is valid; it doesn't need to ask.
Ticket #1732 -- a problem that elicits no error message, but should.
Ticket #1808 -- omitting the "Admin" internal class in certain situations generates the message
'NoneType' object has no attribute 'get_field_sets'
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