Opened 20 years ago
Closed 18 years ago
#1591 closed defect (fixed)
Human readable error messages
Reported by: | rede | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | low | Milestone: | 0.11 |
Component: | general | Version: | |
Severity: | minor | Keywords: | error message |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
In many cases Trac provides very little or very obfuscated error message for end user. It would be beneficial to have proper error handling and reporting in case of failure instead of traceback.
Of course it would be even better to have optional switch to produce tracebacks (to screen and/or to a file) since they provide valuable information for maintainers/developers of Trac.
Attachments (0)
Change History (2)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
Milestone: | → 0.11 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Yes, I think that we generally agree with the intent of this ticket: I can't think of any "legitimate" case where we still produce a traceback; this is always indicative of an error in Trac itself.
Even in that case, we don't show anymore (since 0.11) the traceback to end users, but rather have an explanation redirecting them to their local Trac support. Only the TRAC_ADMIN gets to see the traceback and can eventually promote from there the error to a ticket on t.e.o's Trac.
As sid said, we are open to increase the verbosity/clarity of error messages on a case-by-case basis (e.g. #3839).
I think the general approach (hence the change of type to task) of avoiding tracebacks is now implemented.
Looks like this is being dealt with individually (like #3873, #686, among others). Not sure if there is a good way right now to deal with the entire class of errors that occur…