4 ms·

This will be legal with the proposed `try` statement [0]: info := try(try(os.Open(file)).Stat()) I'm worried about nested versions of this and having to unp

by cfors 7y ago

This will be legal with the proposed `try` statement [0]: info := try(try(os.Open(file)).Stat()) I'm worried about nested versions of this and having to unpack them when reading code, which at the current moment has a much easier imperative block structure. [0] https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md#properties-of-the-proposed-design https://github.com/golang/proposal/blob/master/design/32437-...

pcwalton 7y ago
I've never seen this come up as an issue when reading Rust, which has the same feature being proposed for Go (and then later shortened it to just a single character, ?).
- cfors 7y ago
  Maybe I am caught up in the "not familiar is hard" look of it and will come around. You are most likely correct :)
- Dylan16807 7y ago
  ? is a big improvement over try specifically because you don't have to unpack nested statements. Everything flows left to right.
tgsovlerkhgsel 7y ago
You're right, that's horrible. However, you can also write it like this: f := try(os.Open(file)) info := try(f.Stat()) This can be further improved by applying special syntax highlighting that makes the try less prominent. Meanwhile, the cleanest way to write it right now seems to be: f, err := os.Open(file) if err == nil { return err } info, err := f.Stat() if err == nil { return err } That's 8 lines of code to do the same thing. Did you spot the bug I introduced, or did you miss it because the volume of code made you skim? (error check has == instead of !=)? If you want to judge code by the worst thing you can do, you'd need to compare with things like: var info os.FileInfo if f, err := os.Open(file); err != nil { info, err = f.Stat() } if err != nil { return err } (Did you spot the bug? If err is already declared somewhere further up, this will compile <https://play.golang.org/p/0l-SsEbKQh2> https://play.golang.org/p/0l-SsEbKQh2>, but the "err" within the if shadows the previously declared one, so the errors from os.Open and f.Stat are never checked.)
- Cthulhu_ 7y ago
  > error check has == instead of != And you return the error as-is if its nil; seems fine to me? Your second example is also a bit... far-fetched because it tries to be smart by putting the error checking in the same line. There's also the "line of sight" guideline which states that the happy path should be left-aligned, while edge cases - like errors - should be in indentation [0]. See also the law of least astonishment [1], which your final example does not conform to. Yes it will compile and yes it is an issue but that's not because of the language. It's because of an attempt at cleverness by writing more compact, of having the happy path in an if, and (arguably) by reusing variable names - but this seems pretty common, and longer variable names like idk, `osOpenError` and `fileStatError` seem to be discouraged in favor of reuse. So I'm not sure if you're getting your point across like this. [0] https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88 https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea... [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

by cfors 7y ago

pcwalton 7y ago

I've never seen this come up as an issue when reading Rust, which has the same feature being proposed for Go (and then later shortened it to just a single character, ?).

cfors 7y ago
Maybe I am caught up in the "not familiar is hard" look of it and will come around. You are most likely correct :)
Dylan16807 7y ago
? is a big improvement over try specifically because you don't have to unpack nested statements. Everything flows left to right.

tgsovlerkhgsel 7y ago

You're right, that's horrible. However, you can also write it like this: f := try(os.Open(file)) info := try(f.Stat()) This can be further improved by applying special syntax highlighting that makes the try less prominent. Meanwhile, the cleanest way to write it right now seems to be: f, err := os.Open(file) if err == nil { return err } info, err := f.Stat() if err == nil { return err } That's 8 lines of code to do the same thing. Did you spot the bug I introduced, or did you miss it because the volume of code made you skim? (error check has == instead of !=)? If you want to judge code by the worst thing you can do, you'd need to compare with things like: var info os.FileInfo if f, err := os.Open(file); err != nil { info, err = f.Stat() } if err != nil { return err } (Did you spot the bug? If err is already declared somewhere further up, this will compile <https://play.golang.org/p/0l-SsEbKQh2> https://play.golang.org/p/0l-SsEbKQh2>, but the "err" within the if shadows the previously declared one, so the errors from os.Open and f.Stat are never checked.)

Cthulhu_ 7y ago
> error check has == instead of != And you return the error as-is if its nil; seems fine to me? Your second example is also a bit... far-fetched because it tries to be smart by putting the error checking in the same line. There's also the "line of sight" guideline which states that the happy path should be left-aligned, while edge cases - like errors - should be in indentation [0]. See also the law of least astonishment [1], which your final example does not conform to. Yes it will compile and yes it is an issue but that's not because of the language. It's because of an attempt at cleverness by writing more compact, of having the happy path in an if, and (arguably) by reusing variable names - but this seems pretty common, and longer variable names like idk, `osOpenError` and `fileStatError` seem to be discouraged in favor of reuse. So I'm not sure if you're getting your point across like this. [0] https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88 https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea... [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...