4 ms·
The way errors are handled in go feels like the people were thinking hard "let's not repeat the horror of C++ exceptions" and are ok with ugly warts so long as
by ridaj 7y ago
The way errors are handled in go feels like the people were thinking hard "let's not repeat the horror of C++ exceptions" and are ok with ugly warts so long as they're not uglier than exceptions...
It's clear that there's way too much boilerplate in go procedures that deal with error handling by systematically bailing and passing the failure upstack...
But the most confusing thing to me about try() is that, although it's shaped like a function, it actually returns from the current scope on error. It's dangerous syntactic sugar IMO to make this one function-call-like feature not behave like an actual function call...
- atombender 7y agoToo late, Go already has panic(), which is a magical function that unwinds the stack.
- ridaj 7y ago! So it's legal to write something like... panic(panic()) or a := try(try(f())) ...?
- atombender 7y agopanic() doesn't have a return value, so no. But try() has.