Content-type aware errors

[jkarni]

Combinators should return ServantErrs that match the Accept header when possible. I'd think we can make a datatype for the error, and have the Config contain functions from the datatype and content-type to ServantErr, so e.g. HTML 404 pages are customizable.

[GarrettMosier]

Would you give an example?

[utdemir]

@GarrettMosier maybe this issue was an example: #296

[fisx]

I've seen this problem last week. It was easily solved with a middleware. but yes, I would be happy to have servant do that for me instead.

My idea was to allow for a custom error type with custom instances for ToJSON, ToMarkup, ... I'm not sure though how the library could throw a custom type for e.g. json parse error in the request body. Perhaps instead of having rendering functions in the Config, we could have a single function that that translates the built-in error into a custom error, and then have slightly more convenient content-type dispatch.

A different server monad and an enter won't help either, because all that happens after parsing the request.

That's as far as I got with this. I'm writing it down just because it might trigger a good idea. (-:

[jkarni]

My idea was to allow for a custom error type

This works for user-thrown errors, but I don't see how it would work for combinator-thrown errors. For now I'd be happy with the simpler option of having a fixed datatype.

[fisx]

We've run into this problem and fixed it / worked around it downstream in a fairly elegant way.

wireapp/wire-server#814

There are also some suggestions in the comments on how this design could be improved.

Credit for the elegance all goes to the core servant design that allows you to replace basically any part of the engine with something you can build from scratch. I still think that's very cool!

Also related: #685 #1053