Using RuntimeExceptions and CheckedExceptions

What are you views on using CheckedExceptions and RuntimeExceptions in an application ? I've been advised to use a combination of both and, as fa开发者_Go百科r as I understand, you can have a chain of CheckedException calls being propagated up along with a RuntimeException.

Checked exceptions should only be thrown if you can reasonably expect the caller to handle them. Otherwise throw a RuntimeException (which doesn't require that you declare it or that the handler catch it. This is the approach that Spring JDBC takes).

More details from Sun here.

If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

I agree with Joel.

Take a look at the Fault Barrier pattern: link text

And remember that a checked exception should not expose the internal mechanism of your methods.

A great supplement to the link Joel posted can be found in:

Effective Java Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

in my opinion checked exceptions are a java design flaw (e.g. C# seemed to have learned from it and only offers unchecked exceptions). Sun says you should use checked exceptions if clients could recover. The problem is that as api developer you just don't know, what kind of clients you can expect (->can they recover or not?). Therefore you should not map this uncertainty to your api. So I would go for unchecked exceptions.

In my view when thinking of 'reasonable client handlings' it often happens that in the end you pollute your api. IOException and RemoteException are prominent 'annoying checked exception' examples. In practice they most of the time don't make sense to be handled by clients. Of course in rare cases they make sense to be handled. So looking at this I try to design the api client friendly and avoid the burden of checked exceptions. Of course still when using unchecked exceptions they must be documented (e.g. through javadoc).

Due to down-compatibility of Java most likely the checked/unchecked will never change.

For more details and concrete examples maybe have a look at a blog-post I did some time ago: Getting rid of checked exceptions

Never the less I sometimes still work with checked exceptions for several reasons:

• The existing codebase is big and makes big use of checked exceptions. The effort of refactoring to unchecked exceptions is far too high considering the benefits.
• The majority of team thinks that checked exception are somewhat good and we agreed democratically on several conventions.

Checked exceptions are something that you anticipate and can handle - like IO Exception or DB connection exception. Also, user created exception come under checked exception as well.

Runtime or unchecked exceptions are something that you don't anticipate - they occur due to logical flaws in the code, for eg, arrayindexoutofbounds exception, null pointer exception.

And, to think of it, as a programmer, you create a code that would work well and logically sound and you won't anticipate logical flaws. And, if there were any, the JVM catches and crashes the system.

Hope it helps.

• You should use unchecked exceptions when there is errors in your own code and the application cannot reasonably recover from the error i.e. bugs.
• Use checked exceptions for errors outside the control of your applications, for example bad user input and database connections errors.

Checked exceptions are the expected exceptions.Either you can throw or catch the checked exceptions. By catching it, the recovery from the exception is done by the class itself. By throwing the checked exceptions, you expose the exceptions outside the class and let the outsider handle the exception.

Runtime exceptions arises due to the error in the program. If runtime exception occurs in a class,one cannot except another class to take care of that exception. so, normally runtime exceptions are not thrown.