feature: ability to define custom response error types

[joshmossas]

Let me start by saying that any decisions and discussions regarding this need to be resolved before bumping to v1 because this would be a major breaking change.

Currently arri error responses look like this:

// simple error
{
  "code": 400,
  "message": "There was an error"
}

// more detailed error
{
  "code": 400,
  "message": "Invalid request body. Affected properties: [foo, bar, baz]",
  "data": [
     { "message": "expected string got undefined", "instanacePath": "/foo", "schemaPath": "/FooObject/properties/foo" },
     { "message": "expected float64 got string", "instanacePath": "/bar", "schemaPath": "/FooObject/properties/bar" },
     { "message": "expected boolean got undefined", "instanacePath": "/baz", "schemaPath": "/FooObject/properties/baz" },
   ]
}

code and message are required. data can be anything. code always maps to an HTTP status code.

This is nice because errors always take on the same shape but I find a statusCode + message string to be lackluster as far as error handling goes. What I would really like is the ability to define custom errors that act as either an enum or discriminated union. Then you can handle all of those error cases in a type safe way on the client.

switch (err.type) {
  case "INVALID_PARAMS":
  case "METHOD_NOT_FOUND":
  case "UNKNOWN":
  case "AUTHORIZATION_FAILED":
    break;
}

match err {
  InvalidParams() => {},
  MethodNotFound() => {},
  AuthorizationFailed() => {},
  Unknown() => {}
}

This would make it really easy to provide more explicit context to clients on what went wrong.

Some Considerations

• Would a simple extensible enum field be enough? or would we want to create an extensible discriminator schema that can add additional fields to the error response?
• How can this be done in an extensible and type-safe way?
• should we perhaps make it to where the code field isn't actually an HTTP status code? This would make it easier to support other protocols in the future?
  • If this is the case the "error extension" features need a way to map custom error codes to HTTP status codes
• What should the default error codes be?
  • JSON-RPC has:
    • parse error
    • invalid request
    • method not found
    • invalid params
    • internal error
    • server error (this error type is where implementation specific errors get defined)