The way errors are handled in the SOR depends on the API type, the error in question, and often, conditional logic

• Single object APIs throw
• Some (or most) bulk object API's return an error per-object within the SO entry
• Boom errors are wrapped in a SavedObjectError class
• Extra conditional logic to interpret the error type

This makes it difficult for teams wanting to build features that rely heavily on an error status code and expect a response format to be:

{ saved_objects: [{statusCode: 404, error: 'whatever', ... }]}

but get a response containing a Boom error:

{"saved_objects":[{"id":"fdcffcde431efecb3aba97f56dfbc0b378b8d5be4db5e9a52a591c515589a0b5","type":"cases-oracle","error":{"isBoom":true,"isServer":false,"data":null,"output":{"statusCode":400,"payload":{"message":"[attributes.updatedAt]: expected value of type [string] but got [null]: Bad Request","statusCode":400,"error":"Bad Request"},"headers":{}}}}]}

We need to find some way to improve error handling to make it more intuitive for consumers to build features around these and to clean up code.