7 ms·

What about the way Go handles errors today makes them not "strongly typed"?

swort 10y ago
Typed vs untyped nil means that, in practice, all functions must return an error of type 'error', and force clients to downcast at runtime: https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error Of course, there are ways around this such as returning a struct, but then that's no longer compatible with the error interface.
- mixedCase 10y ago
  > Of course, there are ways around this such as returning a struct, but then that's no longer compatible with the error interface. Which your struct can easily fulfill. That's the beauty of Go interfaces.
  - swort 10y ago
    The linked FAQ specifically talks about returning pointers to structs that fulfil the 'error' interface and why it's a bad idea.
    - mixedCase 10y ago
      The return type would still be the error interface. If you want more information than the error interface you can just use a type switch/assertion.
    - lobster_johnson 10y ago
      It's not that it's a bad idea, just that because of the "nil interface" absurdity it can happen if you accidentally mix concretely typed variables and interfaces, as in the example. This is perfectly valid and doesn't cause the nil issue: return someErrorStruct{} ...where someErrorStruct is a strict that implements the "error" interface. Using structs for errors is fine, and is in fact generally preferable to singletons like io.EOF, which can (by their very nature) never be extended with more data about the error.
      - weberc2 10y ago
        > absurdity There's nothing absurd about it; interfaces are a reference type. If you have a reference to a reference, then checking the "outer" reference for nil doesn't tell you anything about the nullity of the "inner" reference. The advice is just a special case of "don't needlessly use pointers-to-pointers".
        lobster_johnson 10y ago
        Go chose to rely heavily on nil pointers, which is a design mistake (see Tony Hoare's apology for inventing it). The resultant tension between interfaces and nils is, in my opinion, an absurd side effect that cannot be explained away as anything except an ugly wart. We should have something better than this in 2016. I say this as someone who uses Go daily for my work and mostly likes it (despite the many warts).
        weberc2 10y ago
        I don't especially love nil either, but people make too big a deal of it. The only arguments against it are hypothetical scenarios, anecdotal examples, and appeals to Hoare's authority. While there's probably a more ergonomic design, there's no substantial evidence that nil is the catastrophe it's made out to be. Using terms like "absurdity" and "catastrophe" seems overly dramatic without some decent evidence.
        lobster_johnson 10y ago
        I don't think I'm being overly dramatic, actually. I deal with nil oversights on a daily basis during development, and I would say that it is is the main source of unexpected crashes in anything. It equally applies to other languages such as Ruby and Python. It's exacerbated by the fact that Go chose to make things like maps, slices and channels pointers, too. It has an excellent philosophy about zero values (so you can't get nil strings, even though they are pointers internally), yet goofed when it came to something as intuitive as "var foo []string", and claimed this behaviour to be a feature. The (nil, nil) interface is just icing on a crappy cake. The fact that such a new language as Go doesn't have a way to express missing values safely should be disappointing to developers.
PeCaN 10y ago
The compiler provides you no help at all with them, and no syntax that makes error conditions and handling separate. It also mixes application logic and recovery logic. Basically everything that's problematic with returning a status int in C, but all new, hip, and backed up by Rob Pike's pseudointellectual bullshit and a bunch of Silicon Valley 20somethings. They could at least, you know, have an Either type or something. Anything?
- Artemis2 10y ago
  Don't forget Brian Kernighan and Ken Thompson!
- pjmlp 10y ago
  Yes, but at least they are making the tools we may eventually have to rely on due to market pressure (Docker, K8s, ...) in Go instead of C.
- leaveyou 10y ago
  >It also mixes application logic and recovery logic. When did this separation become law ? What if the "application logic" requires recovery ? >They could at least, you know, have an Either type or something (int64, error) in func ParseInt() (int64, error) is your Either type. And checking if you got the "left or the right side of the Either" is IMHO much shorter and clearer than in Scala. https://golang.org/pkg/strconv/#ParseInt https://golang.org/pkg/strconv/#ParseInt http://www.scala-lang.org/api/rc2/scala/Either.html http://www.scala-lang.org/api/rc2/scala/Either.html >backed up by Rob Pike's pseudointellectual bullshit and a bunch of Silicon Valley 20somethings Why the ad hominems ?
  - premium-concern 10y ago
    cringe. How ecactly is having to check twice the amount of cases an improvement (note btw, that checking for Left/Right is doing it wrong)?
    - weberc2 10y ago
aikah 10y ago
> What about the way Go handles errors today makes them not "strongly typed"? Error as type or error as values ? the std lib promotes error as values (i.e. check equality) instead of errors as type (i.e. check the type). Go error system WAS written with errors as value in mind. There is no point having errors in place of exceptions if errors were intended to be used as types (which they are not, as said previoulsy). Basically developers are implementing their own mediocre exception system on top of Go errors. The error as value thing made sense in C 30 years ago, it doesn't in a language created less than 10 years ago. There are a lot of C inspired patterns in Go that make the language half modern/ half dated in strange ways. That's fine when one comes from C though, that isn't when one comes from anything remotely modern. But I guess it's why Go is successful, it's basically C with garbage collection.
- tapirl 10y ago
  error is an interface type is Go, which means an error contains both a type and a value, or "error as type" and "error as value" are both true in Go.
  - aikah 10y ago
    I said that already. And that's not the problem at end. When you test an error, do you test against a value or a type in order to know what kind of error it is ?
    - bassislife 10y ago
      You can test the interface. A type is just an interface around memory, albeit more consrained.
      - aikah 10y ago
        > You can test the interface. A type is just an interface around memory, albeit more consrained. Wow, again, that's not the problem here. Errors in the standard libraries are defined at values. There is no point testing it as interfaces, it will not give you the nature of the error, since they are all defined with fmt.Errorf . Do you understand now the problem ? the problem is being consistant across codebases between errors are values and errors as types.

swort 10y ago

Typed vs untyped nil means that, in practice, all functions must return an error of type 'error', and force clients to downcast at runtime: https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error Of course, there are ways around this such as returning a struct, but then that's no longer compatible with the error interface.

mixedCase 10y ago
> Of course, there are ways around this such as returning a struct, but then that's no longer compatible with the error interface. Which your struct can easily fulfill. That's the beauty of Go interfaces.
- swort 10y ago
  The linked FAQ specifically talks about returning pointers to structs that fulfil the 'error' interface and why it's a bad idea.
  - mixedCase 10y ago
    The return type would still be the error interface. If you want more information than the error interface you can just use a type switch/assertion.
  - lobster_johnson 10y ago
    It's not that it's a bad idea, just that because of the "nil interface" absurdity it can happen if you accidentally mix concretely typed variables and interfaces, as in the example. This is perfectly valid and doesn't cause the nil issue: return someErrorStruct{} ...where someErrorStruct is a strict that implements the "error" interface. Using structs for errors is fine, and is in fact generally preferable to singletons like io.EOF, which can (by their very nature) never be extended with more data about the error.
    - weberc2 10y ago
      > absurdity There's nothing absurd about it; interfaces are a reference type. If you have a reference to a reference, then checking the "outer" reference for nil doesn't tell you anything about the nullity of the "inner" reference. The advice is just a special case of "don't needlessly use pointers-to-pointers".
      - lobster_johnson 10y ago
        Go chose to rely heavily on nil pointers, which is a design mistake (see Tony Hoare's apology for inventing it). The resultant tension between interfaces and nils is, in my opinion, an absurd side effect that cannot be explained away as anything except an ugly wart. We should have something better than this in 2016. I say this as someone who uses Go daily for my work and mostly likes it (despite the many warts).
        weberc2 10y ago
        I don't especially love nil either, but people make too big a deal of it. The only arguments against it are hypothetical scenarios, anecdotal examples, and appeals to Hoare's authority. While there's probably a more ergonomic design, there's no substantial evidence that nil is the catastrophe it's made out to be. Using terms like "absurdity" and "catastrophe" seems overly dramatic without some decent evidence.
        lobster_johnson 10y ago
        I don't think I'm being overly dramatic, actually. I deal with nil oversights on a daily basis during development, and I would say that it is is the main source of unexpected crashes in anything. It equally applies to other languages such as Ruby and Python. It's exacerbated by the fact that Go chose to make things like maps, slices and channels pointers, too. It has an excellent philosophy about zero values (so you can't get nil strings, even though they are pointers internally), yet goofed when it came to something as intuitive as "var foo []string", and claimed this behaviour to be a feature. The (nil, nil) interface is just icing on a crappy cake. The fact that such a new language as Go doesn't have a way to express missing values safely should be disappointing to developers.

PeCaN 10y ago

The compiler provides you no help at all with them, and no syntax that makes error conditions and handling separate. It also mixes application logic and recovery logic. Basically everything that's problematic with returning a status int in C, but all new, hip, and backed up by Rob Pike's pseudointellectual bullshit and a bunch of Silicon Valley 20somethings. They could at least, you know, have an Either type or something. Anything?

Artemis2 10y ago
Don't forget Brian Kernighan and Ken Thompson!
pjmlp 10y ago
Yes, but at least they are making the tools we may eventually have to rely on due to market pressure (Docker, K8s, ...) in Go instead of C.
leaveyou 10y ago
>It also mixes application logic and recovery logic. When did this separation become law ? What if the "application logic" requires recovery ? >They could at least, you know, have an Either type or something (int64, error) in func ParseInt() (int64, error) is your Either type. And checking if you got the "left or the right side of the Either" is IMHO much shorter and clearer than in Scala. https://golang.org/pkg/strconv/#ParseInt https://golang.org/pkg/strconv/#ParseInt http://www.scala-lang.org/api/rc2/scala/Either.html http://www.scala-lang.org/api/rc2/scala/Either.html >backed up by Rob Pike's pseudointellectual bullshit and a bunch of Silicon Valley 20somethings Why the ad hominems ?
- premium-concern 10y ago
  cringe. How ecactly is having to check twice the amount of cases an improvement (note btw, that checking for Left/Right is doing it wrong)?
  - weberc2 10y ago

aikah 10y ago

> What about the way Go handles errors today makes them not "strongly typed"? Error as type or error as values ? the std lib promotes error as values (i.e. check equality) instead of errors as type (i.e. check the type). Go error system WAS written with errors as value in mind. There is no point having errors in place of exceptions if errors were intended to be used as types (which they are not, as said previoulsy). Basically developers are implementing their own mediocre exception system on top of Go errors. The error as value thing made sense in C 30 years ago, it doesn't in a language created less than 10 years ago. There are a lot of C inspired patterns in Go that make the language half modern/ half dated in strange ways. That's fine when one comes from C though, that isn't when one comes from anything remotely modern. But I guess it's why Go is successful, it's basically C with garbage collection.

tapirl 10y ago
error is an interface type is Go, which means an error contains both a type and a value, or "error as type" and "error as value" are both true in Go.
- aikah 10y ago
  I said that already. And that's not the problem at end. When you test an error, do you test against a value or a type in order to know what kind of error it is ?
  - bassislife 10y ago
    You can test the interface. A type is just an interface around memory, albeit more consrained.
    - aikah 10y ago
      > You can test the interface. A type is just an interface around memory, albeit more consrained. Wow, again, that's not the problem here. Errors in the standard libraries are defined at values. There is no point testing it as interfaces, it will not give you the nature of the error, since they are all defined with fmt.Errorf . Do you understand now the problem ? the problem is being consistant across codebases between errors are values and errors as types.