* Chris Morgan: > I would love this to be the case. It's the biggest problem I had with Go's > error handling: that it's far too easy to just ignore a return value > accidentally.
I did an informal study some time ago, and it does not appear to be that common a mistake. (I was biased and tried to prove that the current state of affairs what bad, but the results weren't convincing.) It only happens when there are no results whatsoever. If there are results that need processing, programmers do some form of error handling or threading. There is, however, one major design blunder. Some of the I/O interfaces (Reader, ReaderAt etc.) do not follow the rest of the standard library in treating the result/error return as a sum type. In the rest of the library, you have to check the error first because it is often not possible to see from the result itself that it is part of an error (say, the value 0 from an string-to-inter parsing routine). With I/O, you have to check the result first because some of the interfaces are specified to return both data and an error. Here's an example for io.Reader: <http://golang.org/pkg/io/#Reader> Rust shouldn't have this problem if it uses a proper sum type, and even with Go the language, it would have been possible to avoid this mess with a better choice in Go the library. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
