6 ms·

This is the real danger of the pattern, isn't it? It fades into the background, lulling your eyes into skipping over what's potentially a major source of bugs.

tylerFowler 7y ago
Not more than seeing that an existing function you're extending or otherwise working on throwing its exceptions and saying "Ok I guess something above this will catch my exceptions" and learning to take that at face value. Or at least that's been my experience working on large scale Java projects with teams. From my experience with Go I find that only these lines fade into the background: something, err := someFunc() if err != nil { return nil, err } I find that whenever any actual error handling logic beyond forwarding tends to really jump out at me in code reviews and such.
tptacek 7y ago
It's hard to believe an explicit error check could be more lulling than the invisible exceptions most mainstream languages use.
- KirinDave 7y ago
  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).
- kazinator 7y ago
  Error return values are also invisible. By default, an ignored return code does nothing. The situation is shuffled under the rug. By default, an ignored exception is loud. Error codes have to be handled to become louder. Exceptions have to be handled to become quieter. The control flows underlying exceptions are syntactically invisible except at the source and destination sites. However, they reliably occur. They reliably occur because they are invisible. If exceptions had to be propagated by some visible assistance through all the layers they cross, they would become unreliable. The problem/trade-off with exceptions (the bad aspect of how they are invisible in their own way) is that if we have statements like S1; S2; S3, we can never be sure that S2 is reached, or if S2 is reached then S3. S1 can call some function that throws, and so can S2 or S3. Exceptions can cause partially executed statement flows to be unexpectedly abandoned. And that means that whatever those statements were doing remains half done because the programmer assumed that if S1 is reached, then S2 and S3 are an iron-clad given. Programmers using exception-based languages have to train themselves to use unwind protection mechanisms in all situations fitting the pattern that "if we have executed S1, then S2 must execute to complete/undo/clean-up whatever S1 started". They must never rely on ordinary sequencing, except when it is obvious that the code doesn't throw (for whatever reason: triviality, or all being in the same module put together by that programmer or whatever). If any external code is involved (statements inserted by a macro, foreign callbacks, calls into third party stuff), all bets are off.
  - tptacek 7y ago
    That wasn't the argument Dave made. He said that handled error returns became invisible, because the repetition lulled programmers. That's the argument I felt was untenable. Obviously, Go does some things to mitigate the risk of ignored error returns; the damnable use requirement means that multi-valued functions returning errors either have to explicitly ignore the error by assigning it to "_", which feels as squicky as it should, or be assigned to a variable with which (usually) something must later be done. It's not perfect, I'll freely concede.
    - KirinDave 7y ago
      They.

tylerFowler 7y ago

Not more than seeing that an existing function you're extending or otherwise working on throwing its exceptions and saying "Ok I guess something above this will catch my exceptions" and learning to take that at face value. Or at least that's been my experience working on large scale Java projects with teams. From my experience with Go I find that only these lines fade into the background: something, err := someFunc() if err != nil { return nil, err } I find that whenever any actual error handling logic beyond forwarding tends to really jump out at me in code reviews and such.

tptacek 7y ago

It's hard to believe an explicit error check could be more lulling than the invisible exceptions most mainstream languages use.

KirinDave 7y ago
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).
kazinator 7y ago
Error return values are also invisible. By default, an ignored return code does nothing. The situation is shuffled under the rug. By default, an ignored exception is loud. Error codes have to be handled to become louder. Exceptions have to be handled to become quieter. The control flows underlying exceptions are syntactically invisible except at the source and destination sites. However, they reliably occur. They reliably occur because they are invisible. If exceptions had to be propagated by some visible assistance through all the layers they cross, they would become unreliable. The problem/trade-off with exceptions (the bad aspect of how they are invisible in their own way) is that if we have statements like S1; S2; S3, we can never be sure that S2 is reached, or if S2 is reached then S3. S1 can call some function that throws, and so can S2 or S3. Exceptions can cause partially executed statement flows to be unexpectedly abandoned. And that means that whatever those statements were doing remains half done because the programmer assumed that if S1 is reached, then S2 and S3 are an iron-clad given. Programmers using exception-based languages have to train themselves to use unwind protection mechanisms in all situations fitting the pattern that "if we have executed S1, then S2 must execute to complete/undo/clean-up whatever S1 started". They must never rely on ordinary sequencing, except when it is obvious that the code doesn't throw (for whatever reason: triviality, or all being in the same module put together by that programmer or whatever). If any external code is involved (statements inserted by a macro, foreign callbacks, calls into third party stuff), all bets are off.
- tptacek 7y ago
  That wasn't the argument Dave made. He said that handled error returns became invisible, because the repetition lulled programmers. That's the argument I felt was untenable. Obviously, Go does some things to mitigate the risk of ignored error returns; the damnable use requirement means that multi-valued functions returning errors either have to explicitly ignore the error by assigning it to "_", which feels as squicky as it should, or be assigned to a variable with which (usually) something must later be done. It's not perfect, I'll freely concede.
  - KirinDave 7y ago
    They.