catch checked exception and throw a RuntimeException instead?

[Jan Groth]

Hi there,

I'd like to get your opinion on the following issue:

Is it pattern or an anti-pattern to catch checked exception and throw a RuntimeException instead?

For example, consider the folling situation (B&S certification, by the way):

A server reads a central data file. This is done by a class that can throw a IOException, among others. Assume this class is pretty much down the hierachy. If the server cannot read the file, it cannot work. No need for complex recovery or so, if file i/o doesn't work (maybe the hard drive is unplugged?), i can forget about starting the server.

A possible client connects with the server, working with an adapter-class. The first instantiation of an adapter will cause the server to read the data file.

So, if I consequently hand over the IOException from the FileReader, I end up with a client that wants to read some data and has to handle an IOException from the server.

I feel this is not so smart. Considering a seperation of concerns, the client does not want to know about any IOException on the way to the data (file).

idea 1
Catching the IOException and throwing a RuntimeException. This can be done by a class which directly takes care of reading the data file.

(Definitly not the first one to try this out, if you google for code snippets like this: "catch IOException throw RuntimeException" you'll get thousands of hits... )

idea 2
Throw an Error.

My preferred variant. Like the API-doc says:

A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.

I'd really like to know what others think about this issue... Any other aspects / opinions? Is there a example where it makes sense to hide a checked exception behind a RuntimeException?

Greetings from Berlin,
Jan.

[David C. Meyers]

Jan,

It is a common (and good) practice to catch your Java exceptions and re-throw a specific business exception that you create. This way your client can catch this business exception and display a proper error message instead of just bombing if a runtime exception occurs. A runtime exception is an unexpected result and should not be purposely programmed.

[Steve Morrow]

Use checked exceptions for situations from which you can recover gracefully. Use runtime (unchecked) excpetions for unholy events that signify apocalyptic catastrophes (or at least your application's ability to run properly).

[Mr. C Lamont Gilbert]

Two issues. To change checked into runtime exception. To pass exception to client.

1. Client should receive a ServerException class of your own creating. Client cant do anything about what happens on the server, so Client has no need to know. Send client ServerException so he can cancel the operation gracefully.

2. If you send client runtime exception you will be killing the client for no good reason. I see people argue for converting checked into runtime exceptions. They will not sway me. Its pure lazy and poor programming imho. If you can deal with it even partially, you should.

People dont like to have so many methods throwing checked exceptions. They think its pollution of some form. For me its just dilligence.

[Tony Morris]

You'll find some very hot debate on this topic. Some bigots will claim that the very existence of checked exceptions is a language design flaw. Quite often, this opinion is formed from using .NET and Design By Contract principles (specifying exceptions on a contract (interface) is considered an implementation detail, violating the very purpose of the contract).

However, the truth is that it is the very existence of both unchecked and checked exceptions that is the flaw. In Java, the most optimal workaround when dependant on a third party that uses checked exceptions (or the core API) is to write an equivalent unchecked exception and wrap the checked exception. However, this optimal workaround only holds within the context of Java. A less broken language would have one or the other. Ignore the marketing guff regarding "application exceptions" and "developer induced exceptions" - marketers/poor engineers are not a sound basis for correctness.

There are many flaws in Java; each with its own optimal workaround. For example, the very existence of null can be worked around with runtime fail early (unfortunate); the existence of concrete inheritance can be worked around with an isolation of that concrete inheritance to a single point.

How does a book sound on the topic?

[Stan James]

I have done all my work projects with catching all kinds of exceptions and throwing a checked application specific exceptions. But as an experiment at home I did my Wiki with all unchecked exceptions exactly as you described. The rule is all public methods throw unchecked WikiException only. Internal private methods can throw others because sometimes the calling method wants to take different action on different exception types. Actually that never happened, but that was the theory. Anyhow, given the architecture of the Wiki where all exceptions bubble up to the Runnable that handles an individual user request unchecked exceptions worked beautifully.

[Jan Groth]

thank you all for you replies...

last night i refactored client and server to throw / catch business-specific exceptions. this looks pretty good now in my eyes.

even though i see different issues and alternatives from you points above, i think for me the most important aspect is to follow a clean line in design, which i achieve in the described way.

thanks again,
jan