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.