commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 14357] - static option for reversing the stacktrace
Date Sun, 30 Mar 2003 16:26:22 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14357>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14357

static option for reversing the stacktrace





------- Additional Comments From alex@apache.org  2003-03-30 16:26 -------
"This is not very friendly to users because hopefully the 
highlevel exception will be the best explanation in 9 out of 10 causes,"

This is contrary to my experience.  I find that the higher level exceptions 
usually cloud the issue, obscuring a low-level explanation (e.g. Disk Full) 
with an package-level explanation (e.g. StorageLayerException) that was layered 
on in order to satisfy Java's neurotic exception checking.  In addition, this 
high-level exception has the *wrong* stack trace, since it was thrown from a 
different line of code than the one that caused the error; so you *have* to 
scroll down and then seek back up again to find the start of the real stack 
trace.

"it is only when debugging or in misbehaved exception handling one like to see 
the root causes - and THEN one can go down and read the bottom of the stack 
trace."

I disagree with this statement too.  While I do believe that users should be 
given information when something goes wrong, naive users should never be forced 
to read a stack trace or an exception message.  For them, *any* exception at 
all translates as "Something bad happened (plus technical gobbledegook)."

That means that the *only* users interested in the content would presumably 
only be interested because they are debugging.

It sounds like the bug reporter needs to install a higher-level error handling 
routine in his application.  While throwables can be a nice way to signal 
application errors, there needs to be a different way for your application to 
figure out what message to present to the user.  This can be as simple as "An 
error occured while X" where X is "Loading foo.xml" or "Communicating with the 
server", and you can even generate these by looking at the high-level exception 
and having a mapping table of your own (StorageLayerException -> "Accessing the 
local disk") but displaying "com.myapp.storage.StorageLayerException: ..." to 
the user is already assuming she's technical enough to even bother reading it 
past the "com.myapp.", let alone comprehend it.

After all that, however, I'm not sure what the correct default behavior is for 
lang.exception.  There is a very strong argument that it should behave just 
like JDK; if so, there's another argument that there should be an option to 
reverse it for people like me who prefer it upside-down.

All IMHO, of course... :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message