5 ms·
Two. The URL is a constant that is guaranteed not to return an error. It is not brevity. Anyways, the point is I don't understand the point of err != nil bashi
by rakyll 10y ago
Two. The URL is a constant that is guaranteed not to return an error. It is not brevity.
Anyways, the point is I don't understand the point of err != nil bashing here, given there are two programs in the article that only contain one error check each.
- ben_jones 10y agoAs someone who writes a lot of Go I have mixed feelings about it. The problem is that there are implicit errors regardless and the explicitness in err != nil tricks beginners into thinking that they've covered all edge cases, they haven't. Recover() is probably the only way to handle internal panics and even then it only works if you know to that internal call might call panic(). That said I can't think of an alternative other then to reduce the number of panic()s hidden in various libraries.
- rakyll 10y agoAvoiding error checking against a properly formatted constant is not avoiding error checking. I cannot follow your argument.
- ben_jones 10y agoSorry, I guess I'm not really making one. If anything I'm commenting that (IMO) explicit error handling isn't as explicit as people thing it is. There are internal errors induced by panic() that are really inconvenient.
- mixedCase 10y agoPanics are supposed to be launched on an "end all work on this; code path is FUBAR". On a web server that usually means dropping the connection, logging everything and firing an automated e-mail to the dev team to notify there's a bug in the code that needs to be fixed. All other error conditions are expected and handled. That's what Go's error handling philosophy is all about.
- jimjimjim 10y agopanic should be a "the world is ending" sort of operation.
- justinsb 10y agoThis is turning into a major tangent, but where is the guarantee documented?