3 ms·
I really wish people would stop trying to "fix" Go error handling. Go error handling is fine. If you want a terse language, use something else. Go error semant
by svnpenn 4y ago
I really wish people would stop trying to "fix" Go error handling.
Go error handling is fine. If you want a terse language, use something else. Go error semantics have been this way for over a decade, they aren't going to (and shouldn't) change. The whole point of the current syntax is so that YOU DON'T IGNORE ERRORS. People keeps saying, "BUT MY LOC", just simply don't get it. You're supposed to do something with the error, either return it up the stack, or decorate it, or log it. Go didn't choose the exception route, stop trying to bolt exceptions on, and just adapt or stop using Go.
- ownagefool 4y agoAdmittedly I'm probably just not the best programmer in the world, but I just copy and paste something like this: if err := c.ShouldBindHeader(&headers); err != nil { log.Println(err.Error()) c.JSON(http.StatusUnauthorized, gin.H{"error": err.Error()}) return } I don't think I give any more or less thought about it overall. Honestly, I'd probably rather just write the happy path, but still like the language either way.
- the_gipsy 4y agoIn my experience, errors still get ignored - by accident. The err var juggling sometimes can't even be checked by a linter. And of course it's just EXTREMELY verbose. Compare to rust, where it's not verbose at all, AND the type system is sufficient to force you to handle errors.