3 ms·

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 prob

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.
    - randomdata 3y ago
      With respect to Python, what is the practical difference between: try: something() except FooError as err: raise BazError("something bad happened", err) except BarError: return 1 and err := something() switch { case errors.Is(err, FooError): return 0, NewBazError("something bad happened", err) case errors.Is(err, BarError): return 1, nil } ? I see no meaningful difference at all. The only thing that stands out to me is that Go version gets you thinking about errors more (although not as much as some other languages), not being sourced from something bolted onto the side. In Python, you are more likely to lazily call something() blissfully unaware that an error may occur. Is the problem actually not with Go per se, but that people don't want to be reminded that errors are a thing, presumably because they don't want to put in the hard work to properly deal with them? It is quite true that properly dealing with errors is hard work. Really hard work. But it is also the most important code in your application, so I posit that it is work worth doing.
      - JodieBenitez 3y ago
        > In Python, you are more likely to lazily call something() blissfully unaware that an error may occur. It's not about being lazy or unaware (frankly, that's condescending). No matter the language, IDEs are pretty clear about what errors a something() could trigger. It's not about terseness of the code either. Again, IDEs will just fold all the "if err != nil" blocks so I don't care. It's about separation of concerns. Example: If I develop an app which rely on external resources such as an API or database, there may not be any reason to manage all of their possible failures upfront, right in the middle of the so-called "happy path" of the current business logic. Just let the connection error bubble up and do right thing (ie. rollback whatever you had, log the error and display a nice message to the user, or whatever is needed) elsewhere where this error dealing is centralized along with all http transport shenanigans. That's kinda like the Java checked exception thing: annoying with no real benefit. These days I port an app to Go. And I really like some of the things it brings to the table (mostly unrelated to the language semantics though). But it also feels incredibly archaic at times, error handling not being the only culprit here.

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.
  - randomdata 3y ago
    With respect to Python, what is the practical difference between: try: something() except FooError as err: raise BazError("something bad happened", err) except BarError: return 1 and err := something() switch { case errors.Is(err, FooError): return 0, NewBazError("something bad happened", err) case errors.Is(err, BarError): return 1, nil } ? I see no meaningful difference at all. The only thing that stands out to me is that Go version gets you thinking about errors more (although not as much as some other languages), not being sourced from something bolted onto the side. In Python, you are more likely to lazily call something() blissfully unaware that an error may occur. Is the problem actually not with Go per se, but that people don't want to be reminded that errors are a thing, presumably because they don't want to put in the hard work to properly deal with them? It is quite true that properly dealing with errors is hard work. Really hard work. But it is also the most important code in your application, so I posit that it is work worth doing.
    - JodieBenitez 3y ago
      > In Python, you are more likely to lazily call something() blissfully unaware that an error may occur. It's not about being lazy or unaware (frankly, that's condescending). No matter the language, IDEs are pretty clear about what errors a something() could trigger. It's not about terseness of the code either. Again, IDEs will just fold all the "if err != nil" blocks so I don't care. It's about separation of concerns. Example: If I develop an app which rely on external resources such as an API or database, there may not be any reason to manage all of their possible failures upfront, right in the middle of the so-called "happy path" of the current business logic. Just let the connection error bubble up and do right thing (ie. rollback whatever you had, log the error and display a nice message to the user, or whatever is needed) elsewhere where this error dealing is centralized along with all http transport shenanigans. That's kinda like the Java checked exception thing: annoying with no real benefit. These days I port an app to Go. And I really like some of the things it brings to the table (mostly unrelated to the language semantics though). But it also feels incredibly archaic at times, error handling not being the only culprit here.