Very little error logic in the context of a sessionless server requires handling close to the point of error - requests should either succeed or fail en mass fo

Very little error logic in the context of a sessionless server requires handling close to the point of error - requests should either succeed or fail en mass for easier reasoning and retry from the client end, which means no recovery. Which means you need to abort when you find an error condition, and roll back everything, all the way up the stack. The more stateful your problem domain, the more likely you need recovery logic, and error codes start becoming more useful. Add in nondeterminism and error conditions are non-exceptional and exceptions are often not the best model for them.