3 ms·
One of my favorite episodes of the 99% Invisible podcast was about “Good Egress”[0]. It talked about the history of fire escapes and why you don’t see metal fir
by teeray 5y ago
One of my favorite episodes of the 99% Invisible podcast was about “Good Egress”[0]. It talked about the history of fire escapes and why you don’t see metal fire escapes hanging out the side of buildings any longer. The reason for this is that in an emergency, people tend to exit the way they entered. Consequently, that’s why buildings now have central fire stairs.
Error handling in Go is similar. Errors are not something that live outside the flow of control. When they’re out of sight, they become like the fire escape with a barbecue on it or that’s covered in snow in the winter. Even if they’re just being passed up the call stack, they’re at least being handled and you can see exactly how. If they’re not being handled, static analysis can tell you.
It’s not perfect. I’ve had times where I’ve grown tired of writing `if err != nil`. The difference is at least I do it more often in Go, rather than scratching my head trying to figure out bespoke error management in projects written in other languages or whether my error is worthy of being an Exception.
EDIT: added link to 99PI
[0] https://99percentinvisible.org/episode/good-egress/ https://99percentinvisible.org/episode/good-egress/
- erik_seaberg 5y agoI don’t need to punitively reread “if there is an error, stop and return it to the caller” a thousand times a day, for the same reason that I don’t need to read the code that sets up a stack frame for a function call. I think I want an editor mode that just displays the 30% that does something.