I'm not sure I follow the first paragraph, but what I'm trying to say is that the JVM can, at any point, present an unchecked exception, or an error. In that ca

I'm not sure I follow the first paragraph, but what I'm trying to say is that the JVM can, at any point, present an unchecked exception, or an error. In that case, at the very least, all resources have to be released, and nothing should possibly be left in an invalid state. All this while the stack is unwinding. It's unnecessary to communicate that some call might fail. It's even misleading: a novice might handle a checked exception and rollback some state, but not think of all the implicit exceptions that might occur, e.g. a stack overflow. I'm not even talking about subsystems being replaced by distributed versions (so now there are networking errors too) or similar issues arising from composability. So resource allocation and state logic should be written in a way that assumes everything can crash and burn at any time. And then one can sprinkle recovery and retry logic on top of it, but only in very specific cases, and on specific layers of the application.