4 ms·
I think that the difference between the Go way and exceptions is that exceptions are “automatic” and thus invisible. In a language with exceptions what you get
by ainar-g 7y ago
I think that the difference between the Go way and exceptions is that
exceptions are “automatic” and thus invisible. In a language with
exceptions what you get up-stack is probably something like:
FooException at /path/to/useless/file_1.x:42
/path/to/useless/file_1.x:69
/path/to/useless/file_2.x:108
…
/path/to/you/get/the/idea.x:100500
While in properly-wrapped Go code you might get something like:
performing request "abcd-1234" on host "pickles-1":
requesting "storage-4":
querying database "primary":
profile:
not found
And yes, you can attach code location information as well. See, for
example, how Rob Pike et al. do error handling in their Upspin
project[1] or the popular github.com/pkg/errors module[2].
Can you do that with exceptions? Of course! The problem is that
suddenly your code will start to look a lot like "if err != nil".
[1] https://commandcenter.blogspot.com/2017/12/error-handling-in-upspin.html https://commandcenter.blogspot.com/2017/12/error-handling-in...
[2] https://godoc.org/github.com/pkg/errors https://godoc.org/github.com/pkg/errors
- apta 7y ago> I think that the difference between the Go way and exceptions is that exceptions are “automatic” and thus invisible That exceptions automatically take care of propagating context is a big plus. > See, for example, how Rob Pike et al. do error handling in their Upspin project[1] The fact that there needs to be an entire blog post just to explain how to use errors in golang properly is quite telling about how poor of a job it does. Not to mention all the hoops they have to jump to propagate useful information, all of which we already have in languages with exceptions.