5 ms·
> 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. ch
by 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 agoerror 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 agoI 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 agoYou 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.
- pjmlp 10y agoWe do have the same problem in Java and .NET though. I have already used libraries that catch the exceptions internally and return some kind of error value instead. :(
- aikah 10y agoNeither the Java std lib or the .NET std lib do that though, they don't declare an exception as a static constant you need to compare with. Because it's (rightfully so) considered bad coding. Exceptions give you some valuable informations like stack traces. Go errors gives you nothing. They are inferior to Exceptions and a relic of C programming patterns.
- Matthias247 10y agoThat's because single error instances are much cheaper than always creating a new instance of a given type. No need to create garbage for lots of common errors. Of course you could have a dedicated type plus a singleton implementation of it in Go. But what would be the advantage? Checking if err.(type) == io.EofType does not give you more information the only checking if err == io.Eof, as long as you don't store any error instance related information in it. Which makes sense for custom errors and which Go absolutely allows you to do.
- bassislife 10y ago> they are all defined with fmt.Errorf No, an error implements the error interface. It means that it can be a value of any type that implements the constraint of having an Error method.
- aikah 10y ago> No, an error implements the error interface. It means that it can be a value of any type that implements the constraint of having an Error method. It doesn't matter what a value implements if you don't test its content by type. Std lib errors are meant to be tested by value, not by type. It has nothing to do with interfaces again. When you get a std lib error in order to know what error it is you compare it to an exported value, not its type. I don't know why you keep on insisting on interfaces that's not the core of the issue here.