Earlier quoted context omitted.
We are in the distributed systems age. If systems are composable, operations can fail for reasons that are completely unfathomable to the client. It's not reasonable to have a SharkBitTheOpticFiberCableException and 100,000 other ones that handle every reason why an operation failed. What the client should know is how an error affects what it is doing, it wants answers to questions like * Is it likely this error will…
While I think this is a good point, a lot of the answers cannot be determined by the generator of the exception. Your SQL library cannot know what the implications of an error are -- is this a minor part of the system for which the error can be logged but mostly ignored, or is it critical? Etc. People want error handling to vanish so that they can follow the "normal" flow, but in fact error handling is one of the cri…
The server doesn't know what you want to do with a 400 but it knows that the problem is with the request for example.