Absolutely not - the people who do that, don't understand the difference between refusal (precondition not met), and failure (unexpected system error). In your

Absolutely not - the people who do that, don't understand the difference between refusal (precondition not met), and failure (unexpected system error). In your particular case above, I would never let IOException leak "up" into a client-facing contract. How could I? I would have designed that interface long before implementing it. No, in that case, this is an unexpected system error - for example, an unchecked RuntimeException in Java. Just because people don't know how to write software contracts properly, doesn't mean that languages and protocols should remove the notion of a checked exception. When used properly, they are an essential part of an understandable contract. And that's before we even look at it from a type system point of view, where it's absolutely silly to use the same response message to represent either success of failure, greatly increasing the cognitive overhead of the developer calling your service.