Checked exceptions are meant to be thrown in situations that represent not unexpected behavior that should't happen (eg a division by 0) but situations which may arise and for in which the programmer should take care of managing them.
This is a design of Java language and Java API which works quite well because you always know what you are supposed to care about when using an API which provides functionality that can lead to special situations that you should handle.
I don't see the point of forget about checked exceptions, of course you can encapsulate everything that can raise an exception so that you manage internally what is happening and just throw an unchecked (custom) exception but you do have to care about these problems anyway.
The only safe approach I can see is something like:
class UncheckedFileNotFoundException extends RuntimeException {
..
}
class Foobar {
public static void method(String path) {
try {
FileReader reader = new FileReader(path);
}
catch (FileNotFoundException e) {
// code;
throw new UncheckedFileNotFoundException();
}
}
}
But this doens't solve the problem: if the file is not found then the caller should do something accordingly and allowing him to just ignore the exception or hiding the fact that the method could throw one (because you don't have the commodity of throws FileNotFoundException
in method signature) doesn't improve anything.