In 2022, I did this weird little experiment where I redesigned the net/http Handler in #golang. Rather than having a ServeHTTP(w, r) method, I instead broke it into two parts - a handler, and a responder that is returned from the handler. ๐งต๐
The motivation here was seeing people creating custom handlers that return an error.
In many cases, the handler with an error return value was used so that errors could easily be returned like they are in other Go functions. This also made it easy to centralize error handling/rendering logic.
So, why did I go for an even funkier design?
My motivation here was similar to that of the error return value, except I wanted to see what it was like to always return something, whether it was an error or a successful response.
My motivation here was similar to that of the error return value, except I wanted to see what it was like to always return something, whether it was an error or a successful response.
While using this approach I found it had a few perks, but it also made a few things more annoying to do. The biggest drawback was how weird it looked compared to the standard library. That alone is probably reason enough to not use this approach in a real app.
This was all just a thought experiment to see what was possible and how it worked. If you want me to write a larger write-up and share the code a like/share will help me know there is interest -
Loading suggestions...