The exception thrown from methods within a particular library should not affect any code other than the immediate client (as you appear to say). If the methods within this library throw a checked exception, then you can throw a RuntimeException (if you feel that nothing can be done because of the seriousness of the error). All the same, there are times when the client knows better than the library what constitutes an error from which recovery cannot occur.

There is a preferable alternative. Client code can throw its own checked exception (supplying the checked exception you just caught as the cause). This latter technique forces a cascade of similar decisions from client to client. I believe that this is the correct technique. The cause information is preserved in the event that one who debugs may find it useful, but the bounded context is kept free from these details in outer scopes.

I like to create checked exceptions in the code I write because I want to do more than inform client code of the nature of the problem when it happens; I want to force client code to statically acknowledge the possibility of it happening exists (by forcing it to catch). Client code may undermine this obligation by rethrowing unchecked exceptions and this is OK. Therefore, the fact that my library throws a checked exception doesn’t deeply upset your client code or its clients.

Well, you don’t appear to argue against my thesis, but you like C# which does insofar as it steals my ability to throw checked exceptions (or maybe it is .NET and not C# which does this, but I don’t care).

This is a theft most worthy of a rant!

I was more saying it’s better not to bubble up Checked Exceptions like the OgnlException up our code since classes further away don’t actually care about that specific error. In this example they would just care that there was a problem building Foo.