File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Catching Throwable: Good or Bad?

 
Junilu Lacar
Bartender
Pie
Posts: 6563
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 Lacar
Bartender
Pie
Posts: 6563
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Michael Morris
Ranch Hand
Posts: 3451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Pie
Posts: 6563
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 6563
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Pie
Posts: 6563
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2984
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic