3 ms·

So, your argument is that - because you actually see some code that simply propagates an error, it's easier to reason about where the error ends up being handle

So, your argument is that - because you actually see some code that simply propagates an error, it's easier to reason about where the error ends up being handled? That's like saying you'd rather search for a needle in a haystack than a needle on a platter. With un-checked exception handling code, all I have to do is look for "catches" in the call stack to my function. That code stands out and it's easy to find. With Golang, I have to spend way more energy analyzing every caller in the stack because they all touch my error.

sagichmal 12y ago
> So, your argument is that - because you actually see > some code that simply propagates an error, it's easier > to reason about where the error ends up being handled? Not just where the error gets handled, but how it flows through the execution path of your code -- but, yes. > That's like saying you'd rather search for a needle in > a haystack than a needle on a platter. I'm sorry, but I don't see how this follows at all. > With Golang, I have to spend way more energy analyzing > every caller in the stack because they all touch my > error. Spending time thinking about the error path for all of your code is time well spent, because it's necessary if your code is going to function correctly. Deferring consideration of failure results in dangerous (at best) and/or broken (at worst) systems. I hope this is noncontroversial.