4 ms·

Assigning errors at the function call... Worst part of go. Just add try/catch already.

sethammons 3y ago
it is my second or third favorite part of Go. What sucks more than just about anything is exceptions as control flow. It is a spooky GOTO at a distance. To everyone who complains about the "if err != nil { return err }", honestly, you are doing it wrong or you have a toy application. I have written several, large, high scale, highly available systems processing multiple billions of requests a day. When analyizing those code bases, empty error returns like that accounted for 4% or less of our code. We always were doing _something_ with the error. Metrics, logging, reties, sending off to a different workstream, etc.
- deagle50 3y ago
  It's not just the empty return. It's that every fallible function call starts with `err = foo()` or `value, err = foo()`. You're forced to read `err` at the beginning of every function call even if you don't care. How will sugar for an empty return or appending an error handling scope harm anything?
  - deagle50 3y ago
    And I understand the advantages over exceptions, but we've made some nice progress since the mid 2000s. Sum types and error unions aren't rocket science and even the assembly line programming model that Go seems to have built to enable could adopt them up in a day. You could even have `catch` capture only the last value in the result tuple and it would still be big improvement.
    - sethammons 3y ago
      sum types and pattern matching are great. For me, I'm anti-exception. "Point on the doll where the exceptions hurt you." I worked on a project with exceptions as control flow (cough, twisted python, cough), and the error handling was caught several classes and mixins up and over in the file directory. In some far away file, your exception triggered a callback or an errback, and if that excepted, similar magic happened. It got to the point that several engineering choices had to be made around "well, this really would be nice to have an exception and some standard handling, but the framework will take it and do strange things." I _love_ handling my errors where they are created.
coffeebeqn 3y ago
How is try/catch any better? It messes with your scope and is not really any prettier
- deagle50 3y ago
  What do you mean? To me it's not even close. value, err := foo(); if err != nil { // handle err }; value := foo() catch err { // handle err }
wwarner 3y ago
go has panic and defer for exception-like flow control, so you’re free to use it and advocate for it, but most go programmers prefer errors as values.
randomdata 3y ago
> 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.

it is my second or third favorite part of Go. What sucks more than just about anything is exceptions as control flow. It is a spooky GOTO at a distance. To everyone who complains about the "if err != nil { return err }", honestly, you are doing it wrong or you have a toy application. I have written several, large, high scale, highly available systems processing multiple billions of requests a day. When analyizing those code bases, empty error returns like that accounted for 4% or less of our code. We always were doing _something_ with the error. Metrics, logging, reties, sending off to a different workstream, etc.

deagle50 3y ago
It's not just the empty return. It's that every fallible function call starts with `err = foo()` or `value, err = foo()`. You're forced to read `err` at the beginning of every function call even if you don't care. How will sugar for an empty return or appending an error handling scope harm anything?
- deagle50 3y ago
  And I understand the advantages over exceptions, but we've made some nice progress since the mid 2000s. Sum types and error unions aren't rocket science and even the assembly line programming model that Go seems to have built to enable could adopt them up in a day. You could even have `catch` capture only the last value in the result tuple and it would still be big improvement.
  - sethammons 3y ago
    sum types and pattern matching are great. For me, I'm anti-exception. "Point on the doll where the exceptions hurt you." I worked on a project with exceptions as control flow (cough, twisted python, cough), and the error handling was caught several classes and mixins up and over in the file directory. In some far away file, your exception triggered a callback or an errback, and if that excepted, similar magic happened. It got to the point that several engineering choices had to be made around "well, this really would be nice to have an exception and some standard handling, but the framework will take it and do strange things." I _love_ handling my errors where they are created.

coffeebeqn 3y ago

How is try/catch any better? It messes with your scope and is not really any prettier

deagle50 3y ago
What do you mean? To me it's not even close. value, err := foo(); if err != nil { // handle err }; value := foo() catch err { // handle err }

wwarner 3y ago

go has panic and defer for exception-like flow control, so you’re free to use it and advocate for it, but most go programmers prefer errors as values.

randomdata 3y ago

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