Re: Choosing not to throw exceptions like IllegalArguementException

Robert wrote:
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

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.

Users appreciate having the program do what they expect, or tell them 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.

Truth be told, these types of bugs should be caught in your unit-tests, and the exceptions left in place. GUI code is often harder to unit-test, but the point is that if you can't come up with a sensible default value, don't come up with a nonsense result. Users will be more disappointed with nonsense than with error messages.

Daniel Pitts' Tech Blog: <>