#19923: traceback handling in management commands
--------------------------------------------+--------------------
Reporter: nkryptic | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Management commands) | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------------+--------------------
The default behavior for management commands to suppress tracebacks,
unless the `--traceback` option is provide can lead to confusion. While
the single-line `CommandError` output is superb, both in it's simplicity
and accuracy and the output for other errors raised directly in the
management commands are generally clear, the output for errors occurring
elsewhere leave users wondering what to do.
For example, runserver provides some clear error messages:
$ ./manage.py runserver hostname.example.com
...
CommandError: "hostname.example.com" is not a valid port number or
address:port pair.
or:
$ ./manage.py runserver 80
...
Error: You don't have permission to access that port.
Now, see what happens when I make a mistake in my code:
$ ./manage.py shell
...
ImportError: cannot import name model
So, I left the `s` of `models` somewhere in my code, but I have no idea
where. Oddly enough, the runserver command will provide a traceback
without needing `--traceback`:
$ ./manage.py runserver
Validating models...
Unhandled exception in thread started by <bound method Command.inner_run
of <django.contrib.staticfiles.management.commands.runserver.Command
object at 0x101d7e310>>
Traceback (most recent call last):
...
File "/home/me/projects/testproject/testapp/views.py", line 5, in
<module>
from . import model
ImportError: cannot import name model
Over the past few weeks, the number of times that I've helped someone by
simply introducing them to the use of `--traceback` on #django was a
shock.
Here are some options to consider which may improve this situation:
1. Always display the tracebacks. The concise messages provided from
`CommandError` will still be displayed at the end, although the length of
the traceback may diminish the visibility of it. This would lead to the
deprecation of the `--traceback` option.
2. If `--traceback` isn't provided when running a command, append
something like the following after the pretty error is displayed:
add --traceback to the prior command to display more information
about the error
3. Introduce users to `--traceback` usage early. Perhaps a subsection in
the tutorial discussing that everyone will make mistakes writing code and
how you would go about debugging them in with Django?
4. Update the management commands to wrap all localized errors with
`CommandError` and the format the display of all `CommandError`s without
any traceback. Any other error raised would always be formatted and
displayed with it's traceback. This also would lead to the deprecation of
the `--traceback` option.
I'm in favor of simply always displaying the tracebacks. I'm not sure how
feasible !#4 would be, but if it is possible and straightforward to do,
that would be even better.
--
Ticket URL: <https://code.djangoproject.com/ticket/19923>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
