GeeCON Prague 2014*
The moose likes Java in General and the fly likes Why  extend 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 "Why  extend RuntimeException?" Watch "Why  extend RuntimeException?" New topic
Author

Why extend RuntimeException?

Nadine McKenzie
Ranch Hand

Joined: Feb 15, 2002
Posts: 53
Can someone tell me why I would want to create a base exception class that extends RunTimeException? We are using jdk 1.3 and using exception chaining.


Nadine -SCJP, SCWCD, SCBCD
Neeraj Dheer
Ranch Hand

Joined: Mar 30, 2005
Posts: 225
ever wondered why you never have a try-catch block for catching NullPointerException but always have a try-catch or throws for IOException?

There are two types of Exceptions:

1.Checked.
2. Unchecked.

1. Checked : these have to be caught explicitly, meaning either in a try-catch block or declared to be thrown in the 'throws' clause. Ex : IOException

2. Unchecked : these need not be explicitly caught. Ex: NullPointerException
Exceptions subclassing either from the class Error(used to denote some Exception that is beyond the control of your application, like a network failure or something) or from the class RuntimeException are 'unchecked' exceptions. Exceptions like NullPointerException, ArrayIndexOutOfBoundsException subclass from RuntimeException and hence are 'unchecked'. the logic behind this being that if your logic was correct, these Exceptions should not have been raised in the first place.

Normally, custom exceptions are sub classed from the Exception class and are 'checked' exceptions.
So, unless you have a good reason to make your exception an 'unchecked' one, you should not sub class from RuntimeException.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This is a controversial area in some circles. A number of expert OO folks (who mostly came from other languages that do not have checked exceptions) believe that you can do perfectly well with unchecked exceptions all the time. I tried this with one project as an experiment and really liked the results, but I think that was due to the structure of the code and it might not work at all well for others. Far and away the majority of the Java community uses exceptions as the language designers intended (described above) and avoid throwing unchecked ones.

BTW: What I did ...

No public methods declare any exceptions. They catch any checked exceptions and throw an app-specific unchecked exception. The original exception is chained in for debugging.

The app is a web server with a thread per user request model. Once an exception happens there's nothing much I can do about it, so the only "catch" for the unchecked type is at the very beginning of the call stack within the thread, and it just shows an error page.

The advantage is that no public methods declare exceptions and I never have to put calls to those methods in try-catch blocks. Clean & simple, but not for every app.


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
Nadine McKenzie
Ranch Hand

Joined: Feb 15, 2002
Posts: 53
That's is an interesting approach, but not the one we are using. We have 2 base exception classes, one that extends RuntimeException and one that extends Exception.

Both base classes are identical in every other respect. Both are mimicking the JDK 1.4's built in exception chaining in our JDK1.3 code. Here's a code snippet...


private Throwable cause = null;
private boolean initialized = false;


public CascadeException() { super(); }

public CascadeException(Throwable cause) {
this();
initCause(cause);
}
public Throwable getCause() { return cause; }
public Throwable initCause(Throwable cause) {

if(cause == this) {
throw new IllegalArgumentException("cause cannot be this");
}

if(initialized) {
throw new IllegalStateException("initCause already called");
}

initialized = true;
this.cause = cause;

return this;
}

I'm still puzzled as to why we would want to extend RuntimeException. My hunch was it was because we are using EJB local and remote... but that was just a guess. Any ideas?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
It may just be somebody wants the 1.4 features in a 1.3 environment. Exception chaining is a neat concept, something I've been doing for a long time on my own. Of course to convert a 1.3 unchecked exception to your own custom exception you'll have to catch the unchecked one somewhere. In a remotable EJB it would be pretty straightforward to catch them in all public methods and rethrow your custom, but also easy to forget. As I recall my original reason for making custom exceptions in an EJB app was that stack trace information I wanted to use in the client was transient and was lost in the remote calls.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
I'm still puzzled as to why we would want to extend RuntimeException. My hunch was it was because we are using EJB local and remote... but that was just a guess. Any ideas?

For consistency, I follow the EJB spec for all my exception handling: the application (expected) exceptions are checked and the system (unexpected) exceptions are unchecked, ie of type RuntimeException.

So, I do what you do: create a custom application exception (subclass of Exception) and a custom system exception (subclass of RuntimeException). Each class will have whatever overloaded constructors and any additional methods which are needed. Whenever a low-level exception is thrown which you won't want the client to receive, eg SQLException, you just catch it, wrap it in your custom system exception and throw it. Note that in this particular case a checked exception has been converted to an unchecked exception.

So, whether I am developing an EJB or non-EJB application, I have the same basic exception handling strategy in place.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
 
GeeCON Prague 2014
 
subject: Why extend RuntimeException?