5 ms·
> There's an inherent asymmetry No there's not. People seem to just want to ignore all errors, and let the language "figure it out", AKA exceptions. If you wan
by svnpenn 4y ago
> There's an inherent asymmetry
No there's not. People seem to just want to ignore all errors, and let the language "figure it out", AKA exceptions. If you want to ignore errors, then just go all the way and do that:
result, _ := db.GetUser("12345")
then, you never have to worry about errors, you can just code in bliss and wait for the "panic" because you didn't want to bother with proper error handling.
- peterashford 4y agoThat really misrepresents how exceptions are used, IMO.
- sidlls 4y agoDepends on the code base, as usual, and the quality of the development practices the code was written in. Same as go's error handling, actually.
- xigoi 4y agoWith exceptions, you can handle the error in the place that can handle it. That's not the case with your example.
- bheadmaster 4y agoActually, your example would continue running the happy path as if the error didn't happen, returning erroneous results, but not panicking: func main() { x, _ := getNonZero() fmt.Println("Nonzero number:", x) } func getNonZero() (int, error) { return 0, errors.New("oops") } The "_" is supposed to be used only when you're absolutely sure that error cannot happen (e.g. the function you're calling is partial, but you know that the input is in the defined set).