4 ms·
> The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective. H
by __david__ 14y ago
> The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective.
Having done a lot of straight C programming in my life, the error handling in Go is very familiar. Most C code returns errors and doesn't use exceptions (though I have used setjmp()/longjmp() fairly successfully at times).
In practice, the code is more verbose with Go's style of returned errors, but requires you to think more explicitly about errors and recovery, resulting in potentially better code overall.
However, since Go doesn't have an RIAA like C++ and doesn't have "goto" like C, it makes cleaning up from errors more ugly and repetitious (and potentially error prone). File handling, in particular, is causing me headaches right now (getting files closed on errors). I am admittedly a Go newbie, so I may be missing some style that makes it cleaner.
- timewasted 14y agoGetting files closed on errors should look something like: file, err := os.Open(filename) if err != nil { // handle the error however you see fit } defer file.Close() // continue working, knowing that file.Close() will be called when the surrounding function returns See: http://golang.org/doc/effective_go.html#defer http://golang.org/doc/effective_go.html#defer
- __david__ 14y agoAh! Thanks! I had seen panic/recover but hadn't caught "defer". That will make my code much better.