Dear Readers, Whenever I create my Exception classes I always extend it from Exception class. I never extend its subclasses. I am not sure whether its advisable to do that.
With Best Regards,
Shyam Prasad Murarka
Joined: Oct 02, 2003
Hi Shyam, If an exception class extends RuntimeException, it's called unchecked exception. We don't have to put codes that can throw unchecked exceptions inside try blocks nor add throws clause to methods that contain codes that can throw unchecked exceptions.
I rephrase my question: How do we decide whether we should create a checked or an unchecked exception? [ June 09, 2005: Message edited by: Yosi Hendarsjah ]
My personal opinion on this issue is to never use a RuntimeException. These exception can only lead to unpredictable behaviour. If a runtimeexception is thrown and it is not caught the exception is thrown to the upper level. This creates very unreadable stack traces. If an checked exception is thrown is must be caught and so the developer has to think about handling it.
Only when I have to modify some code and can not alter the API I would throw an unchecked (runtime) exception.
In my view, the key question is this: can the client recover (do something useful) when an exception is received? If "yes", then throw a checked exception, if "no", then throw an unchecked exception. If you only throw checked exceptions, ask yourself if it is wise to wrap that NullPointerException caused by your programming bug in a checked exception and throw it to the client.
There is something else. If your code can cause some low-level checked exception to be thrown, eg SQLException, then it is almost always right to wrap and throw it as a RuntimeException as the client would not expect to receive SQLException. In the EJB world, this is the sort of thing which is done (EJBException, a subclass of RuntimeException, being the wrapper class that is used).
Young software teams generally start out using many fine-grained checked exception types. As the team matures, they realize that having all the application's exception types inherit from a single custom type simplifies a lot of code. After more time passes, they often make that single type a RuntimeException, simplifying code more and centralizing much of the error handling.
C++ has optional exception specifications, meaning that a method can be declared to throw; but if you don't declare it, then you can't assume anything. The result was a total mess for a while until people figured out that they were simply bad, and conventional C++ wisdom is now to never use these specifications, essentially making all exceptions into unchecked ones. But the conventional wisdom is also to treat everything as if it might throw. This is how many Java teams work.
This is a contentious question and you will find some very smart folks who think checked exceptions were a bad idea from the start. They suggest you use unchecked exceptions all the time.
I did this as an experiment in style on one system and the structure of the system made it work out very well. It doesn't really attempt to recover or do anything different based on any exception, but lets them all bubble up to a common point that just tells the user something didn't work. From the Crude But Effective school.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Sep 29, 2002
A major concern for me is that a non-EJB application may one day be developed into an EJB application. If the exception handling strategy is not designed along EJB lines, you will have a big problem.
In any case, I've not had any real issues with the way that EJB exceptions are specified, so I'm quite happy to maintain the distinction between application and system exceptions for both EJB and non-EJB applications. It makes life a lot easier if you follow a single, consistent exception handling strategy.