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
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.

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: <http://virtualinfinity.net/wordpress/>
.



Relevant Pages

  • Re: Choosing not to throw exceptions like IllegalArguementException
    ... preventing debug from happening at all. ... like a recipe for converting easily debugged problems into subtle wrong ... 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. ...
    (comp.lang.java.programmer)
  • Re: toward null-safe cookie cutter Comparators
    ... Sometimes I doubt that you have worked in a lot of brownfield ... because the customer would not complain as much. ... How does the customer *ever* see an exception? ... Reality is that I dislike to deliberately introduce a bug to my code, ...
    (comp.lang.java.programmer)
  • Re: How to pop the interpreters stack?
    ... because this isn't a bug. ... The fact that the exception is generated deep down some ... traceback are relevant and which aren't. ... lies in the input rather than some internal error in some subroutine you ...
    (comp.lang.python)
  • Re: Any Clojure users here?
    ... I've also fixed the minor bug in your code, to wit, it did Swing ... I actually prefer forcing programmers to add some kind of exception ... likely nil or a collection containing a nil where the ... And really, when you look deeply into it, the checked exceptions emperor ...
    (comp.lang.lisp)
  • Re: Find rare bugs - SEH and c++ exception handling
    ... Unfortunately the bug occurs only "on the read" it's not that easy (or ... I can't introduce MessageBoxes because they ... It really seems that I neet a lot of patience. ... When the kernel detects an application exception, ...
    (microsoft.public.pocketpc.developer)