* Steven Blenkinsop: > On Friday, 18 October 2013, Florian Weimer wrote:
>> It's more common to simply return the object. >> > > Only in toy programs, or where there is no meaningful additional > context. Sure, but it's a shame that the call stack is discarded if there isn't meaningful context. >> Due to some obscure feature of Go's type system, error values have to >> be interfaces and cannot be struct types > Struct types can be put in interfaces and extracted using type assertions, > such as the error returned by os.Open. However the general case is to use > textual errors. The problem is that if err is of type "error", "err != nil" is true after the assignment of a pointer value to err. So the usual error checking idiom doesn't work if your function returns a pointer-to-struct (that implements the "error" interface) instead of a (relatively opaque) "error" interface value. Or put differently, if you put a typed null pointer into an interface value, the interface value keeps the type information and is therefore no longer equal to nil. >> , so I have not seen anyone >> trying to updating an existing error. Wrapping might happen, but >> there is no general chaining mechanism like there is in Java. k> > The default is fmt.Errorf for textual errors. That's not a chaining mechanism. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
