No, the one mentioned above makes it easier to not break clients. A language that exports an API without checked exceptions can change the implementation and break clients silently in production. A language with checked exceptions will not break clients silently, ever. That's strictly superior from a robustness perspective.

If, as a library author, you want to define a strict contract with clients that you never break, then you explicitly specify the exception signature and you don't let the exceptions be inferred. Then if the implementation changes in a way that introduces a new exception that doesn't match the client contract, then the API author gets the error at compile-time.

That depends a bit on the definition I guess - let me explain why:

If you call a method in e.g. Java which is annotated to return a string, then by definition you have to expect the following possible outcomes:

- The method returns a string

- The method throws an exception (or rather: a Throwable)

- The method does not return at all

That's just how it is in Java and also in most other languages. Therefore, throwing an exception must always be expected. Only if there were only checked exceptions and no unchecked exceptions this would be different - but then how do you handle things like Stackoverflow or OOM exceptions?

In fact, if a methods says it returns a string, what that really means is that that it will not return something else than a string. That is the real meaning. It cannot e.g. return an integer. But that's about all the guarantees that it gives.

So you see, it's tricky.

There are however languages where you can really rely on that they do return what they claim. But those languages then force you to prove that a method actually returns within a finite amount of time and such things. Not very practical to use in many cases.