Hacker News new | ask | show | jobs
by dhagz 1513 days 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.

1 comments

> 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?