File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Catching Throwable: Good or Bad? 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 » Java » Java in General
Bookmark "Catching Throwable: Good or Bad?" Watch "Catching Throwable: Good or Bad?" New topic
Author

Catching Throwable: Good or Bad?

Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5264
    
    9

Seemingly conflicting advice in these articles:
"Streamline Your Exception Processing"
JavaPro, March 2003
"Breaking Java exception-handling rules is easy"
JavaWorld, Feb 2003
"Java Tip 134: When Catching Exceptions, Don't Cast Your Net Too Wide"
JavaWorld, Feb 2003
I can't remember what Joshua Bloch says in "Effective Java" but in general, I have always leaned towards what the last article above advises.

Thoughts?


Junilu - [How to Ask Questions] [How to Answer Questions]
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5264
    
    9

OK, let me elaborate a little bit.
The first article recommends "Always catch java.lang.Throwable unless you have specific error processing for more specific errors or exceptions."
The second article says that it's sometimes OK to catch Throwable, especially when calling external code.
The last article says "Never catch Exception or Throwable if you can help it."
I don't doubt that catching Throwable may be OK in some situations. I just don't know if I'd recognize those situations. More important, I guess, would be to know when not to catch Throwable.
I can think of one: When you are being lazy or rushed or both, and you just want to make some code compile, you really should resist the urge to just catch Throwable or even Exception. This more than likely will not get revisited and will give hard-to-find bugs a place to hide in your code. Follow the advice of the last article: "Catch the most specific exception that you can."
Can anyone else give some good examples of when catching Throwable or Exception is not a good practice?
[ March 26, 2003: Message edited by: Junilu Lacar ]
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Junilu,
Actually, I meant to respond to this earlier but got distracted. I did peruse the first article and I totally disagree with that bozo. I think the only time you should catch a generic Throwable is if something wierd is going on that you can't figure out. Once you do, then that code should be removed. After all, what are the chances of recovery if that Throwable happens to be an Error ancestor? I can see the benefit of occasionally catching a RuntimeException but on a very limited basis. For example catching a SecurityException if you can provide an alternative course of action.
Michael Morris


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
This is what Joshua Bloch has to say about exceptions:
39: Only use checked exceptions for exceptional conditions (not normal processing).
40: Only use checked exceptions of you can recover
41: Avoid unnecessary use of checked exceptions
42: Favor the use of Standard Exceptions vs custom Exceptions
43: Moderate use of "Exception Translation" is good. = Catch an exception IF you can throw a more meaningful one for this situation.
44: Document using the @throws
45: Make the exeption spit out everything that it knows
46: Don't damage the state of the object during and exception
47: Empty catch blocks are a no-no


"JavaRanch, where the deer and the Certified play" - David O'Meara
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451

47: Empty catch blocks are a no-no

What about InterruptedExceptions on wait()s? I've always ignored those. What should you do in that case?
Michael Morris
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5264
    
    9

Thanks Michael,
I read that first article with quite a bit of consternation. I learned about it after a discussion with a colleague about what he had done in one of the classes in our application. What I didn't understand either was that the author appears to be an experienced developer-- he even holds the position of "architect" :roll: Hmmm...
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5264
    
    9


What about InterruptedExceptions on wait()s? I've always ignored those. What should you do in that case?

At the very least, put a comment like
/* empty */
/* ignored */
/* this block intentionally left blank */
On our projects, we have to put at least one statement that logs the exception.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5264
    
    9

This is what Joshua Bloch has to say about exceptions:
40: Only use checked exceptions of you can recover
44: Document using the @throws

Exactly. Since Throwable includes Error and its descendants, there is a chance that you will catch something that you can't recover from. Also, documenting that Throwable can be thrown doesn't really help a whole lot.
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2864
    
  11

Originally posted by Michael Morris:

What about InterruptedExceptions on wait()s? I've always ignored those. What should you do in that case?
Michael Morris

There's also the case of closing I/O streams or sockets, which in theory can throw IOException. I usually leave those catch blocks empty too, but you could at least have a log in there. The argument, "It will never happen," is answered by, "Then logging won't slow it down."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Catching Throwable: Good or Bad?