5 ms·

Just a tiny bit of sugar would go a long way silencing 50% of the complains about error handling in go... Not an error handling improvement per-se, but if we h

Just a tiny bit of sugar would go a long way silencing 50% of the complains about error handling in go... Not an error handling improvement per-se, but if we had to sprinkle just one line of code instead of three around all spots of error handling, that would make me so much happier :-) From: if err != nil { return err } To: return err if err != nil ... that is, allow ruby-style placing of conditionals after the return.

akira2501 3y ago
In these cases I'll almost always name the output error parameter. func x() (err error) The short variable declaration syntax only requires that _at least one_ name is unique, so you can freely use the variable even in := sequences. So you end up with something like: if thing, err := impl(); err != nil { return } else { // use thing } In the articles first example, the "problem" is that you have a core of a method that can return error or a widgetJSON. There should be a separate function that does precisely that. If you want to mash your http logic and your use logic into the same function, you're going to have a mess no matter how hard you try.
- emmanueloga_ 3y ago
  What I'm suggesting would make this snippet nicer too: return err if thing, err := impl(); err != nil // use thing It would remove the indent, and plus you wouldn't need to name your return variable, that can sometimes be error prone (say, if you end up returning the wrong thing). Just a lil bit of sugar!
  - calebio 3y ago
    I might be in the minority here, but IMO that snippet does not look nicer and looks pretty ugly. You've got like 3 things going on all jumbled together. I would not want to encounter that line of code in the wild, or 3 months after writing it, and attempt to parse what it's doing.
  - randomdata 3y ago
    Obviously in real code you need to return a new error each time, not simply pass on the error you received. In actual usage, it seems that one line is going to become painfully long, or span multiple lines in some way. Do you still think that is an improvement once you move past this contrived example?
    - emmanueloga_ 3y ago
      So two things: * in the wild, a LOT of code has the archetypical 3 lines: if err != nil { return err }, so I'm suggesting a lil sugar will remove this noise from countless lines of code across a lot of projects. * If more processing is needed (ex: wrapping the error), use a function (return Wrap(err, ...), etc) or just revert to the normal if syntax.
      - randomdata 3y ago
        > in the wild, a LOT of code has the archetypical 3 lines: if err != nil { return err } The data collected during the "try" proposal evaluation told that is not true. It was occasionally found, but not all that commonly. Maybe there is "a LOT" if you are counting comments with made up example code on HN? But as far as actual codebases that are compiled and run go... There is also a concern, if included just because, that it would encourage developers to start using `return err` where they shouldn't. Which, as you know, would lead to the errors becoming unusable. > If more processing is needed How about some concrete examples and how you see them being formatted? You might have a good idea here, but it's not clear what it would look like in something real. > or just revert to the normal if syntax. If it is only useful for `return err`, why bother? That would be like adding special loop syntax that is only for counting from 0-9. Yeah, maybe once in a blue moon you really will count from 0-9 and it'll be cool on that day, but in reality it's not general enough to warrant inclusion in a language. That said, I do like that your idea does not need to be limited to errors. A lot of error-related ideas are quite flawed in that they only work for errors. In reality, all of the problems with errors in Go are also problems for every other type. The right solution to improve upon those problems will equally solve for email addresses and birthdays.
- menthe 3y ago
  I hope you realize that this won’t even compile. The err in your if is a newly allocated variable by :=, different than the err allocated by the x prototype, and you’d also return a nil error even if impl returned an error. The Go compiler is smart enough to prevent you from doing this beginner mistake: result parameter err not in scope at return. inner declaration of var err error. https://go.dev/play/p/VdWVOL51wZf https://go.dev/play/p/VdWVOL51wZf You would have to first declare thing prior to the if statement, then replace := by = .. the beauty of adding verbosity and longer-lived variables for the sake of trying to write return instead of return err in Go.
  - akira2501 3y ago
    I wrote it that way because that was I was looking at in the example code. You're mostly right. The example from my own code, of course, looks more like this: https://go.dev/play/p/qdjnH3JhzTN https://go.dev/play/p/qdjnH3JhzTN Which does work because the rules on := are loose, but the if captured version creates a new scope that can't be shared with the return variable.
ibraheemdev 3y ago
Formatting the if onto a single line gets you most of the way there. if err != nil { return err }
- emmanueloga_ 3y ago
  Not a bad idea actually! I would be happy with this too! It would require changing go's fmt to allow inline code in braces if it consists of a single return... that would be backward compatible with other code too (just make fmt not revert the previous style to a single line).
ChrisTrenkamp 3y ago
[dead]
kyrra 3y ago
Goland collapses this to a single line, and vscode is looking into it too. https://github.com/golang/vscode-go/issues/2311 https://github.com/golang/vscode-go/issues/2311 It papers over the issue, but helps some.
- cosmicradiance 3y ago
  Alternatively, there is an extension - `Lowlight Go Errors` by Ozan Hanedan. https://marketplace.visualstudio.com/items?itemName=ohanedan.lowlight-go-errors https://marketplace.visualstudio.com/items?itemName=ohanedan...
  - emmanueloga_ 3y ago
    Yay! I like this! Also, I feel validated... this has been installed 6,142 times :-)

akira2501 3y ago

In these cases I'll almost always name the output error parameter. func x() (err error) The short variable declaration syntax only requires that _at least one_ name is unique, so you can freely use the variable even in := sequences. So you end up with something like: if thing, err := impl(); err != nil { return } else { // use thing } In the articles first example, the "problem" is that you have a core of a method that can return error or a widgetJSON. There should be a separate function that does precisely that. If you want to mash your http logic and your use logic into the same function, you're going to have a mess no matter how hard you try.

emmanueloga_ 3y ago
What I'm suggesting would make this snippet nicer too: return err if thing, err := impl(); err != nil // use thing It would remove the indent, and plus you wouldn't need to name your return variable, that can sometimes be error prone (say, if you end up returning the wrong thing). Just a lil bit of sugar!
- calebio 3y ago
  I might be in the minority here, but IMO that snippet does not look nicer and looks pretty ugly. You've got like 3 things going on all jumbled together. I would not want to encounter that line of code in the wild, or 3 months after writing it, and attempt to parse what it's doing.
- randomdata 3y ago
  Obviously in real code you need to return a new error each time, not simply pass on the error you received. In actual usage, it seems that one line is going to become painfully long, or span multiple lines in some way. Do you still think that is an improvement once you move past this contrived example?
  - emmanueloga_ 3y ago
    So two things: * in the wild, a LOT of code has the archetypical 3 lines: if err != nil { return err }, so I'm suggesting a lil sugar will remove this noise from countless lines of code across a lot of projects. * If more processing is needed (ex: wrapping the error), use a function (return Wrap(err, ...), etc) or just revert to the normal if syntax.
    - randomdata 3y ago
      > in the wild, a LOT of code has the archetypical 3 lines: if err != nil { return err } The data collected during the "try" proposal evaluation told that is not true. It was occasionally found, but not all that commonly. Maybe there is "a LOT" if you are counting comments with made up example code on HN? But as far as actual codebases that are compiled and run go... There is also a concern, if included just because, that it would encourage developers to start using `return err` where they shouldn't. Which, as you know, would lead to the errors becoming unusable. > If more processing is needed How about some concrete examples and how you see them being formatted? You might have a good idea here, but it's not clear what it would look like in something real. > or just revert to the normal if syntax. If it is only useful for `return err`, why bother? That would be like adding special loop syntax that is only for counting from 0-9. Yeah, maybe once in a blue moon you really will count from 0-9 and it'll be cool on that day, but in reality it's not general enough to warrant inclusion in a language. That said, I do like that your idea does not need to be limited to errors. A lot of error-related ideas are quite flawed in that they only work for errors. In reality, all of the problems with errors in Go are also problems for every other type. The right solution to improve upon those problems will equally solve for email addresses and birthdays.
menthe 3y ago
I hope you realize that this won’t even compile. The err in your if is a newly allocated variable by :=, different than the err allocated by the x prototype, and you’d also return a nil error even if impl returned an error. The Go compiler is smart enough to prevent you from doing this beginner mistake: result parameter err not in scope at return. inner declaration of var err error. https://go.dev/play/p/VdWVOL51wZf https://go.dev/play/p/VdWVOL51wZf You would have to first declare thing prior to the if statement, then replace := by = .. the beauty of adding verbosity and longer-lived variables for the sake of trying to write return instead of return err in Go.
- akira2501 3y ago
  I wrote it that way because that was I was looking at in the example code. You're mostly right. The example from my own code, of course, looks more like this: https://go.dev/play/p/qdjnH3JhzTN https://go.dev/play/p/qdjnH3JhzTN Which does work because the rules on := are loose, but the if captured version creates a new scope that can't be shared with the return variable.

ibraheemdev 3y ago

Formatting the if onto a single line gets you most of the way there. if err != nil { return err }

emmanueloga_ 3y ago
Not a bad idea actually! I would be happy with this too! It would require changing go's fmt to allow inline code in braces if it consists of a single return... that would be backward compatible with other code too (just make fmt not revert the previous style to a single line).

ChrisTrenkamp 3y ago

[dead]

kyrra 3y ago

Goland collapses this to a single line, and vscode is looking into it too. https://github.com/golang/vscode-go/issues/2311 https://github.com/golang/vscode-go/issues/2311 It papers over the issue, but helps some.

cosmicradiance 3y ago
Alternatively, there is an extension - `Lowlight Go Errors` by Ozan Hanedan. https://marketplace.visualstudio.com/items?itemName=ohanedan.lowlight-go-errors https://marketplace.visualstudio.com/items?itemName=ohanedan...
- emmanueloga_ 3y ago
  Yay! I like this! Also, I feel validated... this has been installed 6,142 times :-)