3 ms·
One of my pet peeves about Go is a lot of errors are not exposed as public variables, so your options of handling them are somewhat limited other than a generic
by fyfy18 7y ago
One of my pet peeves about Go is a lot of errors are not exposed as public variables, so your options of handling them are somewhat limited other than a generic "something went wrong". I've recently written a tool that classifies various http request errors (think SSL failure, not a 500 status code), and have had to have a deep dive into Go reflection as part of that.
I understand part of this is because they don't want to have to worry about making potentially breaking changes - but what I've had to do means my code will break if the internal API changes, and as it's using reflection the compiler won't catch it. It would be nice to have a "yes I know I shouldn't, but I really want to" (ala Ruby's send method) way of doing this that the compiler will still check.