3 ms·
That's not true. All errors adhere to the error interface [0] and can be parameterized as such. It's not significant different to subclassing a stdlib Error cla
by themartorana 10y ago
That's not true. All errors adhere to the error interface [0] and can be parameterized as such. It's not significant different to subclassing a stdlib Error class in another language and using reflection or down-casting to get its sub-type.
So almost all packages either return a base error, or a custom error type that adheres to the error interface.
[0] https://golang.org/pkg/builtin/#error https://golang.org/pkg/builtin/#error
- nemothekid 10y agoI think you missed his point. >Some errors can only be identified by value and others can only be identified by type Let's say I'm reading a csv file, and I need to check whether I'm done reading the file - I'd do something like so: if _, err := csvReader.Read(); err == io.ErrEOF { quit() } However (I can't think of an example off the top of my head), there are many library that make you check the error type to find out what went wrong. if c_err, ok := err.(LibError); ok { c_err.Code } I commonly see this version in libraries that need to return an error with a non-static message (such as the `hostname goolge.com could not be reached`).