drop error_response, add error detail and support for serialization

[tomwojcik]

Closes https://github.com/tomwojcik/starlette-context/issues/58

• starlette errors are returned as PlainTextResponse, so lets do that https://github.com/encode/starlette/blob/389cbfcaa529686bfd4cfab0bfa338a531a389c8/starlette/exceptions.py#L103
• add support for server / client errors. Server errors always return 500. Client errors 4xx with a meaningful message.
• client errors will now return the error message in the response
• drop support for error_response. You said > sending a response object through the exception is weird, but I can't see any other way to make it work nicely with plugins. but I believe changes from this implementation will do the trick.

[hhamana]

I'll have a look at it over the new year

[hhamana]

I believe changes from this implementation will do the trick.

It doesn't. My API needs to have a consistent error schema with the rest of the system, which is a quite custom JSON response. This kills any way for user to customize it to their needs, and enforces a hard-coded non-JSON error message without alternative. I get that you don't like passing a response object through the exception, and I'd want to agree there, but the way plugins work, that was the most straightforward way to escalate it to the handler As this pr hints at, the exception itself can define the response. Sure, but then we need to allow customizing the exception raised, and also modify headers (I'll want the "Content-Type" header to be application/json for a proper JSON response at least) and we'll have to build the appropriate response from scratch in the middleware given the exception's data. I think it's more convenient to have it already build for us there instead, but you'll notice this'll get us back to pretty much the current situation.

Having the default error message as f"Invalid UUID in request header {self.key}" is better for sure though.

[tomwojcik]

My API needs to have a consistent error schema with the rest of the system, which is a quite custom JSON response.

AFAIK that's impossible. Unless you have another layer on top of your starlette-based app, starlette errors return 500 plain text. possibly related https://github.com/encode/starlette/issues/1175#issuecomment-882898895

But I get you. I don't see why both solutions shouldn't coexist, so a default error message and optionally a custom response for errors. I will think about it.

[tomwojcik]

My API needs to have a consistent error schema with the rest of the system, which is a quite custom JSON response. This kills any way for user to customize it to their needs, and enforces a hard-coded non-JSON error message without alternative.

https://github.com/tomwojcik/starlette-context/pull/59/files#diff-4a0aecbfe7f993c2281b848a8b4269204420d30388706ddea3bc26dbfd2b1171R51-R64

wdyt?

[hhamana]

Unless you have another layer on top of your starlette-based app, starlette errors return 500 plain text.

that's if you leave those as errors though. If you handle those and make a response from there somehow, the Starlette layer won't even see it's been an exception.

[hhamana]

wdyt?

I guess the factory approach is workable. It reduces the plugin-specific response to a singular handler on the middleware, but one use I can see is raising the exception internally, to except and extract the exact exception (as different plugins will still raise different subclasses), and a custom plugin can still have its own exception mixed in too.