4 ms·
In Go I not infrequently make use of a non-nil value AND a non-nil error. A canonical example of this is the io.Reader interface in Go's standard library [1].
by rwcarlsen 12y ago
In Go I not infrequently make use of a non-nil value AND a non-nil error. A canonical example of this is the io.Reader interface in Go's standard library [1]. I think it is a very useful idiom particularly when dealing with things where failure is more normal - e.g. dealing with network services, disk IO, decoding partially corrupt exif data from images. Often you want a best-effort at the value even if you run into problems.
[1] http://golang.org/pkg/io/#Reader http://golang.org/pkg/io/#Reader
- pcwalton 12y agoThat can be done by either returning a tuple or providing a way to get a partial value out of your error type. (Result is generic over the error type, so you can add whatever extra data you'd like to your errors without forcing your callers to downcast.)
- sjustinas 12y agoRust team is aware of this and working on a solution[1] as a part of the "IO reform". [1] https://github.com/aturon/rfcs/blob/io-reader-writer/text/0517-io-os-reform.md#nonatomic-results https://github.com/aturon/rfcs/blob/io-reader-writer/text/05...
- masklinn 12y ago> In Go I not infrequently make use of a non-nil value AND a non-nil error. The number of APIs making use of that pattern is very much infrequent, and doesn't justify it for the 99.99% of functions which don't. > I think it is a very useful idiom particularly when dealing with things where failure is more normal And you could have the exact same information by returning, say, `Either (Int, Error) Int`. Or even `Either (Int, Error) ()` since partial writes are apparently considered error cases. Although I would really use a separate data type e.g. data WriteResult = Complete | Partial Int Cause | Error Cause and let the application decide whether a partial write is an error or normal behaviour.