3 ms·

The thing is, a lack of error handling code is a clear sign of deferral. No action is a "pass" up the stack, ultimately to the top loop. In Go, a lack of action

The thing is, a lack of error handling code is a clear sign of deferral. No action is a "pass" up the stack, ultimately to the top loop. In Go, a lack of action is called out, but the policy for pass/keep is explicit on every choice and sometimes can be subtle (for examples of you try to do an http call expecting an error, that looks nearly identical to code that does the opposite. I think that the try() stuff removing the humdrum repetition is a good idea precisely because it makes all explicit error handling stand out like a beacon. I might name it "pass" or something but that's not as important. If I recall correctly, it vaguely resembles a solution you recommended to me on at least one occasion. Keeping things as they are seems to me like the worst possible option.

tptacek 7y ago
I understand your argument and it is coherent, but it isn't persuasive. Yes, you can treat lack of error handling as a clear sign of deferral. In practice, that is not how people treat a lack of error handling. I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read.
- kasey_junk 7y ago
  What I’m curious about is how it will impact shadowing bugs which are the most common I see in practice. My intuition is it will alleviate that but I’m not sure.
- KirinDave 7y ago
  > I understand your argument and it is coherent, but it isn't persuasive. Yes, you can treat lack of error handling as a clear sign of deferral. In practice, that is not how people treat a lack of error handling. To be honest I'm not sure what you're suggesting at all. The reason the default error handling strategy for so man languages is to defer upwards is because that's by far the most convenient behavior for development, and is not the worst decision in prod. Folks don't seem to find it confusing. Their programs crash with a stack trace. Certainly exception propagation has its own issues, but the default strategy isn't a thing I'd call out as bad. Indeed, if anyone can't produce a good crash-to-stack (cough, Haskell, cough) they get called "unfriendly" for developers.[1] Meanwhile, I'm hardly the only voice in the choir of folks saying that Golang's error handling is frustratingly repetitive and can sometimes introduce surprising issue due to variable reuse, capture and shadowing. > I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read. Both of these can be true without invalidating each other. [1]: This is not to say we can't do better. Common Lisp is quite rightly famous for its Conditions and Restarts which are (imo, of course) pretty much the best error handling system ever created, allowing developers to embed recovery strategies AND rich exceptions in their code with syntactically and semantically obvious constructs and then pass the calling code the responsibility of choosing a mitigation strategy (or crashing).

tptacek 7y ago

I understand your argument and it is coherent, but it isn't persuasive. Yes, you can treat lack of error handling as a clear sign of deferral. In practice, that is not how people treat a lack of error handling. I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read.

kasey_junk 7y ago
What I’m curious about is how it will impact shadowing bugs which are the most common I see in practice. My intuition is it will alleviate that but I’m not sure.
KirinDave 7y ago
> I understand your argument and it is coherent, but it isn't persuasive. Yes, you can treat lack of error handling as a clear sign of deferral. In practice, that is not how people treat a lack of error handling. To be honest I'm not sure what you're suggesting at all. The reason the default error handling strategy for so man languages is to defer upwards is because that's by far the most convenient behavior for development, and is not the worst decision in prod. Folks don't seem to find it confusing. Their programs crash with a stack trace. Certainly exception propagation has its own issues, but the default strategy isn't a thing I'd call out as bad. Indeed, if anyone can't produce a good crash-to-stack (cough, Haskell, cough) they get called "unfriendly" for developers.[1] Meanwhile, I'm hardly the only voice in the choir of folks saying that Golang's error handling is frustratingly repetitive and can sometimes introduce surprising issue due to variable reuse, capture and shadowing. > I agree that "try" is better than the status quo, not because the if statements are lulling, but because they have the effect of triple-spacing Go code and making it harder to read. Both of these can be true without invalidating each other. [1]: This is not to say we can't do better. Common Lisp is quite rightly famous for its Conditions and Restarts which are (imo, of course) pretty much the best error handling system ever created, allowing developers to embed recovery strategies AND rich exceptions in their code with syntactically and semantically obvious constructs and then pass the calling code the responsibility of choosing a mitigation strategy (or crashing).