> Static return types would violated OOP as well if they exposed implementation details unrelated to the result of the operation. You're arguing against a part

> Static return types would violated OOP as well if they exposed implementation details unrelated to the result of the operation. You're arguing against a particular usage of checked exceptions. You don't have to use checked exceptions like that so the argument is not convincing. > If you have a method called GetPrice() that uses a database, you know it, because you have to expose all the possible exceptions. And if you had a method called getPrice() that should always fail if a product is part of a bundle and cannot be purchase separately then you would potentially want every caller to be aware of that possibility. One error condition is an implementation detail and the other is a fundamental invariant of the domain. Guess which one checked exceptions should be used for? > You can't have two different implementations of GetPrice() that are compatible unless they have exactly the same exception result. What's the value of that? That's the whole point. There are invariants that should be communicated in a type-safe manner. The confusion here isn't new and is actually well understood. All error signals fall into two buckets -- does my caller care and can she respond sensibly to it or will she just pass on the error and/or quit. The benefit of checked exceptions is maximum flexibility: you can guess (and it's always a guess) that your caller doesn't care and throw an unchecked exception or, if you feel really strongly that the caller should care because some key invariant has been broken, you can throw a checked exception. It's not an exact science but this question -- does my caller care? -- goes to the very heart of encapsulation and abstraction.