Checked exceptions were/are one of Java's biggest mis-features (IMHO). You can't force a client to deal with exceptions. Checked exceptions ends up encouraging empty catch blocks, which is usually worse than propagating an exception.

I'm a C++ programmer and I wish I had checked exceptions. Checked exceptions are really equivalent to an either monad, except that they look better in imperative code, especially if you lack some sort of 'do' notation.

What Java lacks is a) enough compile time abstraction capabilities to inspect and parametrize exception specifications so that application specific exceptions can be forwarded through generic/framework code and b) a way to defer the checking to runtime (possibly via a special annotation) so that there would be no reason to ever write empty catch blocks.

If the method you're designing is going to throw an exception that wouldn't make sense to handle from a consumer standpoint, creating an exception that extends `RuntimeException` would be my advice. I agree that empty catch blocks are not a good idea.

It would b a good idea to catch it. Except Java has a FileNotFound exception when trying to open something, which to me should just be part of the normal control flow and is not something exceptional.

That and you tend to get code that just "throws Exception" propagated all the way down to main. I know I've done it for little projects at Uni (when I last programmed in Java, 3.0 I think?)