Here's a great StackOverflow question/answer on this: http://stackoverflow.com/questions/4670987/why-is-it-better-...

I program in Java and I like that methods have * to declare what they exceptions they throw. This makes it very obvious from a consumer standpoint.

* except for runtime exceptions

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?)

"Displaying an error message"... where?

This is about embedded systems. quite often there is no user and no display (for status purposes).

An exception is not simply a return statement, which only returns program control to the calling function. An exception can transfer program control to anywhere up the call stack, it really behaves more as a scoped goto with context information than a function return.

Put differently: without exceptions, each function in your call stack is responsible for error handling of its callees, and for returning the correct error information to its caller. With exceptions, you only need error handling at the catch site.

This is one of the opinions the Go language is built around. Exceptions are the one kind of non-local control flow we're still using long after GOTO was deprecated.

longjmp() might be the better analogy.

Returning an error code is error-prone, you need to check for the error code for every function you use.

you also need to handle all exceptions... there is no escape.

to have correct behaviour, all error cases need to have defined recovery. in this, error-return === exceptions.

Not true. If you don't catch an exception, you're automatically saying that it's a problem you can't fix, and your program will be terminated. If you fail to check return codes, then your program tries to keep running in a broken state.

You're misunderstanding...

The whole point is to never run in a broken state.... that path leads to expensive misery.

The point of resetting is to clear out bad state... if the condition has no defined recovery process then you cannot continue safely.

I'm not saying to not handle an error... I'm saying to not attempt recovery from undefined errors.

If you don't know what went wrong, don't attempt to 'handle' it... reset.

The difference is that running in an unknown/broken state is the default when using error codes. Getting into such a state with exception handling typically requires explicit programmer action, such as the "catch everything and ignore it" pattern.

Sorry, that is just wrong headed.

What is needed is true error recovery thought, not syntax that encourages proper to just put in empty exception handlers.

Your point is arguing for error returns in my view.