On Wed, Sep 06, 2017 at 11:00:08PM -0700, Tim Uckun wrote: > Totally not a go programmer but here are my worthless two cents. > > I don't see anything wrong with the try catch paradigm, you can choose your > granularity. If you want to check every call then you can, if you want to > let a few cluster together you can. You guys make is sound like go style > error handling is the only way to catch errors at every step. That's not > true at all. [...]
Actually, I do think there are cases when you don't care which error has actually happened, and where -- you just want to abort processing and quit. Unfortunately, this only works for "batch-style" processing, like shell scripts -- where you want the whole thing to be done, or to fail ASAP should any problem be detected (well, sometimes, though quite much more rarely, you'd even want to merely log errors and continue to chug away with the operations). I have a goto writeup on exceptions bookmarked, which I invite you to read [1]. The key point from it, which pretty much summarizes the idea behind how error handing is done in Go, is: | C++ exceptions … are great for guaranteeing that program doesn't | fail — just wrap the main function in try/catch block and you can | handle all the errors in a single place. | | However, what's great for avoiding straightforward failures becomes a | nightmare when your goal is to guarantee that no undefined behaviour | happens. The decoupling between raising of the exception and handling | it, that makes avoiding failures so easy in C++, makes it virtually | impossible to guarantee that the program never runs info undefined | behaviour. 1. http://250bpm.com/blog:4 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
