Kepler

It would be nice if we provided a way to more effectively hide
the stack traces. Usually, when there is an error, a dialog box
with a meaningful message should come up. One of the buttons
should bring up a window that shows the stack trace.

One problem is that because we use exception chaining, the
exception is actually thrown does not always provide useful information
about what caused the exception, instead there is an earlier
exception that has the real cause.

Unfortunately, it is difficult to determine when to show just
the top exception and when to show one or more cause exceptions.

I feel that it is a bug if:
1) I have to get out the debugger to figure out where the exception
occurred. This happens when we rethrow exceptions without
using a cause argument or when exceptions are ignore.
2) If the error message goes to stderr or stdout

I see the point of providing cleaner exceptions to users, but this
should be balanced with the needs of developers who want to find
out where the exception is occurring.

I suspect that the way to provide better error messages would
be to track new users and see what errors they are seeing and
clean those up. We could either observe users or else instrument
the code and gather reports.

BTW - Edward and I discuss this issue quite a bit. I want
useful messages that might have too much info because I fix lots
of bugs and I provide end supports to users who usually do not
supply enough info. Edward wants a clean interface.

Perhaps by using preferences to manage the output we can provide both.
However, cleaning up the error messages one by one requires time.

_Christopher

Users (except very technical ones) don't usually care about the intricate
technical details that they aren't going to understand anyway. One general
design prinicple is to speak the user's language -- to speak in terms they
understand. However, of course we want a way to help trace bugs and problems
so that developers can fix things.

There are some various ways we could approach this problem. Here are my
recommendations in priority order:

1) provide user understandable error messages when problems occur but record
in an error log the user understandable message and the stack trace or other
important technical details so that there is a "couplet record" of problems

2) provide user understanddable error messages when problems occur, but
provide a button (maybe "Details") on the error message dialog that when
pressed will display the more tecnical aspects

3) provide a user understandable error message first in the error dialog, then
below that provide the technical details helpful to the developer.

In each of these alternatives, the user is presented with an understandable
message but the developer has the option in some manner of obtaining more
information for trouble-shooting and debugging purposes.

If you provide me with some screenshots or user traces of overly complex
error messages, I'll see what I can do. Perhaps you could attach a couple of
screen shots to this bug?

One mistake I make is that I modify the system to suit my needs which does
things like add complexity to error messages etc. Being reminded to keep
the non-technical user in mind is a good thing. Professor Lee often makes
this point as well.

reassigning to Laura, so we don't lose track of Christopher's request:

"If you provide me with some screenshots or user traces of overly complex
error messages, I'll see what I can do. Perhaps you could attach a couple of
screen shots to this bug?"

He or I need specific direction on this, if poss. Please feel free to reassign
back when this info is available

implementation note to me:

When we implement this, need to put the user-visible text values in the
ResourceBundle text file:

configs/ptolemy/configs/kepler/uiDisplayText_en_US.properties

and maybe access them using ptolemy.kernel.utils.StaticResources.java

Still need list of specific issues from Laura

Original Bugzilla ID was 2015