Hacker News Reader

Comment by emmanueloga_ | Hacker News Reader

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.

View on HN

Goland collapses this to a single line, and vscode is looking into it too.

https://github.com/golang/vscode-go/issues/2311

It papers over the issue, but helps some.

Alternatively, there is an extension - `Lowlight Go Errors` by Ozan Hanedan. https://marketplace.visualstudio.com/items?itemName=ohanedan...

Yay! I like this! Also, I feel validated... this has been installed 6,142 times :-)

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.

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

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.

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

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.

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!

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.

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?

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.

> 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.

re: "a lot", I don't have hard data but it is what I see in my own code, code I use and even whenever someone needs to post a lil snippet of code on videos, blog posts, etc. I just feel those three lines are pure friction for no good reason.

I actually like the suggestion below, that would involve just a little, backward compatible, tweak on how fmt works [1].

1: 1 hour ago

tangent: does HN replace links to specific comments like this? "1: 1 hour ago"? I've never seen that, I thought I linked to the specific comment ｢(･ิ.･ิ)

this is so dumb... I think copied the text instead of copying the link source lol

Formatting the if onto a single line gets you most of the way there.

    if err != nil { return err }

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).

Reply on news.ycombinator.com