This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Originally posted by Jack Kay: But I don't see why we should extend Exception, when extending Throwable works just as well.
Basically its a matter of design. Check out the Javadocs for Exception and Error (the two subclasses of Throwable)
Exception: The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch. Error: An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.
Also, from what I remember from my programmer's cert: All subclasses of Exception are "Checked exceptions" meaning that they must be explicitly handled either by a try/catch block or a throws clause. All direct subclasses of Throwable, Error or RuntimeException are "unchecked exceptions" and do not need to be explicitly handled.
So, the question is -- how do you want your exception to be dealt with? What kind of exception is it? Is it something expected taht can happen pretty often and people should need to handle it? or is it very rare and unexpected and when it happens, it means something is really wrong...
Everything that Jess said is correct except that direct subclasses of Throwable are actually checked, not unchecked.
At some level, you want people to be able to say "catch (Exception ex)" and catch only recoverable things; that's the main reason why user exceptions should generally extends Exception. If you extend Throwable, then your type can't be caught generically without also catching junk like OutOfMemoryError at the same time.
You want to group your exceptions into logical subsets, so that by catching one type, you're catching all the exceptions that make sense.
So, say you're writing a poker game, and there are a few bad things that can go wrong during the game: you could shuffle poorly, you could Deal too many cards to a player, or someone could cheat. It makes sense that if any of these things happen -- you would deal with it appropriately. BUT -- if something like an OutOfMemoryError happened, you have no way of "fixing" that problem -- so you don't want to catch that Error along with those exceptions that you actually have a way of dealing with.
So, notice if one of the Exceptions happens that I know I can deal with (Bad deal, someone cheated etc.) I just restart the hand. But if some unknown Error occurred (i.e. something in the Throwable class) -- I exit the game.
Also don't forget, you can catch each exception individually:
Joined: Aug 01, 2004
So extending Throwable are mainly for those really hard errors that occur within the system, and then extending Exception is a bug in the program that can most likely be restored.
The OutOfMemoryError would be something that Throwable would deal with since that's one of the hard errors, and you'd most likely exit the program.
So you catch the ones you can restore (extends Exception), and then with the ones you can't fix, they would probably go to (catch (Throwable e)) with most likely a System.exit(1) ending.
I'm going Ok right?
But earlier you quoted from Java docs about how Errors should not be caught. But if a serious error occurs, shouldn't you catch the Error, and then exit the program? [ August 02, 2004: Message edited by: Jack Kay ]