4 ms·

I would argue that errors per se today are more than sufficient for this, but http.Handler is what's lacking. There's no idiomatic way to abort a multi-handler

I would argue that errors per se today are more than sufficient for this, but http.Handler is what's lacking. There's no idiomatic way to abort a multi-handler chain or to signal an error to a parent handler. This is the #1 value I get out of non-http.Handler-based frameworks like Gin. (RPCs tend not to have a comparable number of layers of middleware and more support for reading "downstream" errors, though I do wish gRPC supported nested interceptors better.)

dhagz 5y ago
I sort of get what you're saying, but at the same time I don't. Any logic that depends on what the "next/child" handler returns can get errors either from the response itself or the context, depending on the approach I want to take (context is probably most idiomatic, but its own bag of worms (I say that because values in the context are all empty interfaces/any type, which is a pain when you want a concrete type)). Unless there's some usecase I'm missing, since I haven't really touched Gin in awhile, and never got too crazy with what I wrung out of it.
- morelisp 5y ago
  > returns can get errors either from the response itself or the context Not really! To get errors "from the response" you're going to have to wrap the entire `ResponseWriter` to pass downstream, which is a) a lot of noise, b) can cause some subtle issues (you didn't really need to also implement Pusher, did you? you're sure no one already called Write(Header) on the thing you're wrapping, right? Ever heard of "requestTooLarger"?). To get errors "from the context", the downstream handler and you need to agree on how to record them. The downstream handler gets your context, you can't get its. So you need to prepare error logging for it, or agree on the same higher-level handler to do it for both of you. You're in trouble as soon as you try to integrate an arbitrary handler - which is the entire point of using the standard handler interface, so why bother? Or is there some magic pattern for either of these I'm missing?
closeparen 5y ago
Fair point. I don’t spend much of my time on middlewares - write once, use forever - but we do have pretty nested and layered architectures between the user-level handler and what it’s ultimately doing. That’s where it’s painful to thread the errors through.

dhagz 5y ago

I sort of get what you're saying, but at the same time I don't. Any logic that depends on what the "next/child" handler returns can get errors either from the response itself or the context, depending on the approach I want to take (context is probably most idiomatic, but its own bag of worms (I say that because values in the context are all empty interfaces/any type, which is a pain when you want a concrete type)). Unless there's some usecase I'm missing, since I haven't really touched Gin in awhile, and never got too crazy with what I wrung out of it.

morelisp 5y ago
> returns can get errors either from the response itself or the context Not really! To get errors "from the response" you're going to have to wrap the entire `ResponseWriter` to pass downstream, which is a) a lot of noise, b) can cause some subtle issues (you didn't really need to also implement Pusher, did you? you're sure no one already called Write(Header) on the thing you're wrapping, right? Ever heard of "requestTooLarger"?). To get errors "from the context", the downstream handler and you need to agree on how to record them. The downstream handler gets your context, you can't get its. So you need to prepare error logging for it, or agree on the same higher-level handler to do it for both of you. You're in trouble as soon as you try to integrate an arbitrary handler - which is the entire point of using the standard handler interface, so why bother? Or is there some magic pattern for either of these I'm missing?

closeparen 5y ago

Fair point. I don’t spend much of my time on middlewares - write once, use forever - but we do have pretty nested and layered architectures between the user-level handler and what it’s ultimately doing. That’s where it’s painful to thread the errors through.