3 ms·

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

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.
  - emmanueloga_ 3y ago
    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
    - emmanueloga_ 3y 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 ｢(･ิ.･ิ)
      - emmanueloga_ 3y ago
        this is so dumb... I think copied the text instead of copying the link source lol

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.
- emmanueloga_ 3y ago
  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
  - emmanueloga_ 3y 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 ｢(･ิ.･ิ)
    - emmanueloga_ 3y ago
      this is so dumb... I think copied the text instead of copying the link source lol