aspose file tools*
The moose likes Java in General and the fly likes Exception or RuntimeException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Exception or RuntimeException" Watch "Exception or RuntimeException" New topic
Author

Exception or RuntimeException

Yosi Hendarsjah
Ranch Hand

Joined: Oct 02, 2003
Posts: 164
Hi all,

When we design an exception class,how to decide whether the class should extends Exception or RuntimeException?
Shyam Prasad Murarka
Ranch Hand

Joined: May 02, 2005
Posts: 209
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
Yosi Hendarsjah
Ranch Hand

Joined: Oct 02, 2003
Posts: 164
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 ]
Manuel Moons
Ranch Hand

Joined: Mar 05, 2002
Posts: 229
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.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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).


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.

Checked exceptions are vastly overused.


[Jess in Action][AskingGoodQuestions]
M Beck
Ranch Hand

Joined: Jan 14, 2005
Posts: 323
off-topic idle thought: how many languages other than Java even have checked exceptions? is this a notion that originated with Java, or was it copied from somewhere else by the Java team?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.

Just for fun, Bruce Eckell vs Sun ...

http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html


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
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Exception or RuntimeException