3 ms·

> Just add try/catch already. Although the keywords panic and recover were chosen instead, this functionality has existed since day one. But we're talking abo

> Just add try/catch already. Although the keywords panic and recover were chosen instead, this functionality has existed since day one. But we're talking about errors here, not exceptions. They are very different things.

deagle50 3y ago
As am I. "try" as sugar for a simple return, and "catch" to capture the error value.
- randomdata 3y ago
  How is that any different from exception handlers, which are so-named because they are for carrying exceptions, not errors? Maybe you're leaving out the stack trace that one usually expects when propagating exceptions? I'm not sure that is meaningfully different, though.
JodieBenitez 3y ago
> But we're talking about errors here, not exceptions. They are very different things. Well, in some languages it's the same and I have yet to come to a practical problem with it being the same.
- randomdata 3y ago
  There are no practical problems found in error handling, period. They aren't anything special. It is no different than handling a person's age, and who has problems with handling that? You have failed to grasp programming at even the most basic level if you are struggling with handling values. The discussion is always just about the pleasantness of the development experience, and exception handlers are simply not pleasant to use (when carrying errors) – to the point that, when using those languages, developers go out of their way to find ways to avoid having to deal with errors to not have to write out the monstrosity that is to catch an error thrown. Indeed, that's life. You have to deal with the hand you are dealt. If that means changing how the application functions to not make your developer life a complete living hell due to quirks of a programming language, so be it. But idealistically, that does not make for a good language design. There is a reason why they are called exception handlers, not stack traversers, or whatever.
  - JodieBenitez 3y ago
    What I mean is that exceptions and try/catch makes a better development experience imo, both for "errors" and control flow and we've been using that for ages with no debate similar to what the golang error handling generates.
    - randomdata 3y ago
      They only give the illusion of providing a better development experience if you forgo dealing with errors. Indeed, there is a class of programming, known as scripting, where errors actually don't matter. If something bad happens you simply fail, deal with the problem through human intervention, and try again later. It is not unreasonable to carry errors up the stack using exception handlers in this type of problem domain. Arguably communicating an error state this way is the best solution we know of to that problem. However, there is another class of programming, known as systems, where error handling is the most important code you will write. This is the domain where exception handlers are just plain not suited to the problem. The idiomatic Go solution is not pleasant, but a huge improvement over dealing with catching exceptions everywhere. As before, because catching exceptions is so painful, many applications that probably should be systems are pushed into being scripts. Which may very well be a good engineering solution to the problem of dealing with a quirky language, but idealistically a programming language will not shape your application requirements like that. But, yes, Go is not at all designed to be a scripting language. It has been quite explicit about that since day one.
      - JodieBenitez 3y ago
        I don't think the scripting/systems distinction matters. After all, Go dragged a lot of Python developers that create more or less the same kind of applications and banckends. They just enjoy added benefits such as easy deployment, faster execution, lower memory requirements, saner dependency management, and more. But I'm pretty sure error handling is not what they like about Go. I sure don't, I just cope with it.
        3y ago
deagle50 3y ago
I'm not asking for exceptions. I'm asking for sugar for an empty return, and most importantly, a way to capture the error value after the function call.

deagle50 3y ago

As am I. "try" as sugar for a simple return, and "catch" to capture the error value.

randomdata 3y ago
How is that any different from exception handlers, which are so-named because they are for carrying exceptions, not errors? Maybe you're leaving out the stack trace that one usually expects when propagating exceptions? I'm not sure that is meaningfully different, though.

JodieBenitez 3y ago

> But we're talking about errors here, not exceptions. They are very different things. Well, in some languages it's the same and I have yet to come to a practical problem with it being the same.

randomdata 3y ago
There are no practical problems found in error handling, period. They aren't anything special. It is no different than handling a person's age, and who has problems with handling that? You have failed to grasp programming at even the most basic level if you are struggling with handling values. The discussion is always just about the pleasantness of the development experience, and exception handlers are simply not pleasant to use (when carrying errors) – to the point that, when using those languages, developers go out of their way to find ways to avoid having to deal with errors to not have to write out the monstrosity that is to catch an error thrown. Indeed, that's life. You have to deal with the hand you are dealt. If that means changing how the application functions to not make your developer life a complete living hell due to quirks of a programming language, so be it. But idealistically, that does not make for a good language design. There is a reason why they are called exception handlers, not stack traversers, or whatever.
- JodieBenitez 3y ago
  What I mean is that exceptions and try/catch makes a better development experience imo, both for "errors" and control flow and we've been using that for ages with no debate similar to what the golang error handling generates.
  - randomdata 3y ago
    They only give the illusion of providing a better development experience if you forgo dealing with errors. Indeed, there is a class of programming, known as scripting, where errors actually don't matter. If something bad happens you simply fail, deal with the problem through human intervention, and try again later. It is not unreasonable to carry errors up the stack using exception handlers in this type of problem domain. Arguably communicating an error state this way is the best solution we know of to that problem. However, there is another class of programming, known as systems, where error handling is the most important code you will write. This is the domain where exception handlers are just plain not suited to the problem. The idiomatic Go solution is not pleasant, but a huge improvement over dealing with catching exceptions everywhere. As before, because catching exceptions is so painful, many applications that probably should be systems are pushed into being scripts. Which may very well be a good engineering solution to the problem of dealing with a quirky language, but idealistically a programming language will not shape your application requirements like that. But, yes, Go is not at all designed to be a scripting language. It has been quite explicit about that since day one.
    - JodieBenitez 3y ago
      I don't think the scripting/systems distinction matters. After all, Go dragged a lot of Python developers that create more or less the same kind of applications and banckends. They just enjoy added benefits such as easy deployment, faster execution, lower memory requirements, saner dependency management, and more. But I'm pretty sure error handling is not what they like about Go. I sure don't, I just cope with it.
      - 3y ago

deagle50 3y ago

I'm not asking for exceptions. I'm asking for sugar for an empty return, and most importantly, a way to capture the error value after the function call.