Patricia Shanahan a ?crit :
Robert wrote:
Patricia Shanahan a ?crit :
...
The worse problem is that the error may not even get logged or noticed,
preventing debug from happening at all. At the best, it indeed seems
like a recipe for converting easily debugged problems into subtle wrong
answer problems.
It's harder to debug, but it worth it for GUI code i think
But does it improve even GUI code?
First consider what happens with exceptions. It should be possible to
organize the deployment so that any uncaught Throwable or hang causes a
restart of the application. From the point of view of the end user, the
screen stops working for a few seconds and then goes back to the initial
page. The event is visible to the people managing the application, and
gets logged with information such as the exception stack trace.
I don't think it's a good idea. We are developping a desktop
application, and an "application restart" is impossible. Imagine the
TreeCellRenderer wich throw an exception, and prevent the JTree from any
repaint success, only because some bug happened before, which broke a
specific assumption, and now there is the "impossible case" happening.
This is "bug handling" since it assumes the less it can.
If the application is competently supported, something that causes that
sort of log entry should get fixed quickly. Even if the log does not
give enough data for immediate resolution, it gives enough information
to enable instrumentation of the method that threw the exception and its
caller.
On the other hand, consider the silent wrong answer case. End users make
vague reports about the application doing something other than what it
was told to do. Often, the end users will not realize there is anything
wrong until some time afterwards. The people managing the application
may not even realise there is a bug, but end start feeling the site is
flaky and avoiding it.
I think that's the point, users won't realize there was a bug, because
they will try a second time, from a previous state, with hopefully more
success.
why it couldn't. You're approach to error handling allows a third
option; don't do what the user expects, and don't tell them why. Whoops.
and the exceptions left in place. GUI code is often harder to
default value, don't come up with a nonsense result. Users will be more