This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of Soft Skills and have John Sonmez on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes I have a slightly unusual exception handling style, do you think it's good design? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "I have a slightly unusual exception handling style, do you think it Watch "I have a slightly unusual exception handling style, do you think it New topic
Author

I have a slightly unusual exception handling style, do you think it's good design?

Jane Jukowsky
Ranch Hand

Joined: Mar 28, 2009
Posts: 145
My standard exception handling clause (for fatal exceptions, and 99% of my exceptions are fatal) goes like this:


ErrorHandler class subsequently uses a pluggable strategy to do something; usually, display a JOptionPane, log it, pop up the debugger if available, and System.exit() if allowed.

I am aware of the fact that I am not exactly supposed to catch a Throwable; I figure, if I ever run into a problem with some exception type (maybe ThreadDeath?), I'll just re-throw it from my ErrorHandler; so far, I've never run into a problem.

Some people had complained about excessive use of fatal exceptions in my code; to me, it amounts to defensive programming. An exception is fatal unless proven otherwise, i.e. unless the programmer has considered and tested the recovery scenario; makes sense to me. This way, developers hear all complaints early, which is a good thing over the long run, even if it might be unpopular. Besides, it's always possible to "un-fatal" all fatal errors at once by plugging in a different strategy class.. though I would not recommend it.

Do you think it's a good idea? If so, am I reinventing the wheel? If not, under what scenarios you think this pattern might NOT work?



David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

I'm not a big fan of static utility classes; irritating to test classes that use them.

If the exception handler needed any local information it seems like it'd be a pain.

I also tend to wrap checked exceptions up in application-specific runtime exceptions (if they're really fatal), so this pattern really doesn't buy me very much, except to irritate Checkstyle (which is occasionally worth it).

I'm not saying it's a bad pattern, I'm just saying it really wouldn't work for me.
Jane Jukowsky
Ranch Hand

Joined: Mar 28, 2009
Posts: 145
Thanks for your feedback David, your opinion much appreciated.

David Newton wrote:I'm not a big fan of static utility classes; irritating to test classes that use them.

How so? My Eclipse handles static classes wonderfully. In any case, there is a non-static strategy behind the scenes.

If the exception handler needed any local information it seems like it'd be a pain.

Like what? This is a generic handler; if any business logic is to occur upon catching this exception, why not just put it in the catch clause before the call to the utility class.

I also tend to wrap checked exceptions up in application-specific runtime exceptions (if they're really fatal), so this pattern really doesn't buy me very much,

It buys you three things:

1) when running under a container that swallows exceptions, it lets you handle them meaningfully; I am using the term "container" liberally here.

2) when running in a debugger, it allows you to scroll up the call stack and examine variables and such. Very handy with hard to duplicate errors such as concurrency errors.

3) it makes it very easy to change the default exception handling policy across an application or suit of applications.

except to irritate Checkstyle (which is occasionally worth it).

That's a bummer. What would Checkstyle say?
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

How so? My Eclipse handles static classes wonderfully. In any case, there is a non-static strategy behind the scenes.

For the same reason that classes using any static utils are more difficult than necessary to test--I can't (trivially) plug in a different implementation.

Like what? This is a generic handler; if any business logic is to occur upon catching this exception, why not just put it in the catch clause before the call to the utility class.

Then what's the point?

1) when running under a container that swallows exceptions, it lets you handle them meaningfully; I am using the term "container" liberally here.

I've never had that issue.

2) when running in a debugger, it allows you to scroll up the call stack and examine variables and such. Very handy with hard to duplicate errors such as concurrency errors.

My debuggers already let me do that.

3) it makes it very easy to change the default exception handling policy across an application or suit of applications.

Guess I've never needed to do that. (Well, perhaps I have, but I use AOP for that.)

That's a bummer. What would Checkstyle say?

"Don't catch Throwable"
Jane Jukowsky
Ranch Hand

Joined: Mar 28, 2009
Posts: 145
David Newton wrote:For the same reason that classes using any static utils are more difficult than necessary to test--I can't (trivially) plug in a different implementation.


Yes you can, if the static class is trivial and uses a strategy behind the scenes. If there is the need to replace the few lines of code that pass the call to a strategy object, then the static class is purely designed.

Then what's the point?

The point is standardization. Most of the time, there is no business logic in my catch clauses, and where there is, 99% of the time it comes on top of the standard logic, not instead of it.

1) when running under a container that swallows exceptions, it lets you handle them meaningfully; I am using the term "container" liberally here.

I've never had that issue.

Why, Swing is one example. Try throwing an exception out of JButton's action, or out of any Swing method. Under some versions of Java, you might be able to catch that using Thread.setDefaultUncaughtExceptionHandler or System.setProperty("sun.awt.exception.handler"), but it does not always work.

2) when running in a debugger, it allows you to scroll up the call stack and examine variables and such. Very handy with hard to duplicate errors such as concurrency errors.

My debuggers already let me do that.

How can it do that if your exception has already been thrown and caught outside of the method, and all your local variables are destroyed?

3) it makes it very easy to change the default exception handling policy across an application or suit of applications.

Guess I've never needed to do that. (Well, perhaps I have, but I use AOP for that.)

Good point. In truth, I started doing it back in 1999, way before AOP, and been thinking of rewriting it using AOP for a while.

That's a bummer. What would Checkstyle say?

"Don't catch Throwable"

Yup, a bummer. Well, can always replace it with catch (Exception) if that's a concern. By the way, any idea WHY catching throwables is considered bad practice? What exactly might happen? (personally, I think folks at Sun were afraid that developers will start silently swallowing OutOfMemoryErrors and such..)

Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
David Newton wrote:
1) when running under a container that swallows exceptions, it lets you handle them meaningfully; I am using the term "container" liberally here.

I've never had that issue.

Others had that issue. Another example is Eclipse Platform. By default Eclipse Platform swallows uncaught exceptions and log them especially when the exception occurs from SWT components.
It's well known for Eclipse plug-in developers that when clicks something and the application just "silences", there is an exception and Eclipse just swallows it.

I'm not sure is this topic about Global Exception handling? If so I think there is nothing wrong about catch Throwable and handle. In AWT application we can register a global exception handler, but in some environment like Eclipse Platform we cannot.

To ensure that we have the same understanding, I think to topic creator doesn't mean to catch every exception using catch Throwable, but he means to use this pattern to catch uncaught exceptions in a unify way, and provide a default implementation for handling uncaught exceptions. Please correct me If I'm wrong.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
 
 
subject: I have a slightly unusual exception handling style, do you think it's good design?