4 ms·

Indeed, Go's position is that your style of programming produces fragile programs, and that it is better to consider the failure modes of each expression as you

Indeed, Go's position is that your style of programming produces fragile programs, and that it is better to consider the failure modes of each expression as you type it, rather than afterwards.

twiceaday 8y ago
This is the position of the Google c++ style guide, from which I think Go borrowed heavily.
jfoutz 8y ago
Seems like breadth first vs depth first search. They will converge at the same answer. Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced. This is really insightful, thank you.
- sagichmal 8y ago
  > Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.
erik_seaberg 8y ago
if err != nil { return nil, err } is ceremony that requires no thought and adds no value. There should be sugar for this so it doesn't completely swamp the tiny minority of cases that actually do something.
- sacado2 8y ago
  I actually rarely type that very snippet. In like 3/4 of the cases, I make the error more specific, like if err != nil { return nil, fmt.Errorf("could not parse file %s: %v", path, err) } the remainder being either the snippet you put above or more complex error management.
  - erik_seaberg 8y ago
    You can enrich err.Error(), but when you do you lose the type of the original error and any other fields it may have had. This is something the language can and should do more reliably (i.e., sugar could mutate err.Error() and prepend "MyStruct.myMethod failed: ", or better yet add a damn stack trace).
- cube2222 8y ago
  I'm always using errors.Wrap or Wrapf otherwise it's hard to find the error cause. I've just created a live template for that in Go, which just puts my cursor in the wrap message to pass along.
- sfifs 8y ago
  This is generally a bad idea in any production code. You normally want to add context to the error so that your logging captures the issue at the very minimum. You may want to do cleanup in the function etc. I almost never have written this style of code in many years now.
- stcredzero 8y ago
  is ceremony that requires no thought and adds no value. Aw, hell no! That's a very easily detectable (anti)pattern! You can scan even a very large code base for that! As noted in other comments, you should be adding some contextual information at this point. Contrast this with having too-much magic, where you might have absolutely no trace in code left. You can't usefully search a large code base for all such relevant blanks.

Indeed, Go's position is that your style of programming produces fragile programs, and that it is better to consider the failure modes of each expression as you type it, rather than afterwards.

twiceaday 8y ago

This is the position of the Google c++ style guide, from which I think Go borrowed heavily.

jfoutz 8y ago

Seems like breadth first vs depth first search. They will converge at the same answer. Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced. This is really insightful, thank you.

sagichmal 8y ago
> Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment. That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.

erik_seaberg 8y ago

if err != nil { return nil, err } is ceremony that requires no thought and adds no value. There should be sugar for this so it doesn't completely swamp the tiny minority of cases that actually do something.

sacado2 8y ago
I actually rarely type that very snippet. In like 3/4 of the cases, I make the error more specific, like if err != nil { return nil, fmt.Errorf("could not parse file %s: %v", path, err) } the remainder being either the snippet you put above or more complex error management.
- erik_seaberg 8y ago
  You can enrich err.Error(), but when you do you lose the type of the original error and any other fields it may have had. This is something the language can and should do more reliably (i.e., sugar could mutate err.Error() and prepend "MyStruct.myMethod failed: ", or better yet add a damn stack trace).
cube2222 8y ago
I'm always using errors.Wrap or Wrapf otherwise it's hard to find the error cause. I've just created a live template for that in Go, which just puts my cursor in the wrap message to pass along.
sfifs 8y ago
This is generally a bad idea in any production code. You normally want to add context to the error so that your logging captures the issue at the very minimum. You may want to do cleanup in the function etc. I almost never have written this style of code in many years now.
stcredzero 8y ago
is ceremony that requires no thought and adds no value. Aw, hell no! That's a very easily detectable (anti)pattern! You can scan even a very large code base for that! As noted in other comments, you should be adding some contextual information at this point. Contrast this with having too-much magic, where you might have absolutely no trace in code left. You can't usefully search a large code base for all such relevant blanks.