* Steven Blenkinsop: > On Saturday, 19 October 2013, Florian Weimer wrote: > >> >> 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.
> Don't do that. Return an error, not a naked error implementation. If people > want to inspect it rather than treat it as a string, they'll do a type > assertion rather than just a nil check. Then the Go-level interface doesn't tell the programmer that the type assertion continues working (i.e., that there is something to which the caller can attach its extra information). > Don't do that. Return either a nil error or a valid value of your error > type. Seriously, the nil interface vs nil contents thing is only a tripping > point for novices who don't understand what interfaces are, it's not > something you run into once you've familiarized yourself with the language. We'll see if that's true once we've got at analyzer that flags this. :-) > That's not a chaining mechanism. > > You're going to need to explain what you mean by this, then, and how it > would apply to Rust. Note that if it's something very particular to how Go > code is written, it's probably not constructive here. Java exceptions have a getCause() mechanism which returns another exception. When you've got a piece of got that needs to provide further context to exceptions that might be thrown by lower layers, it can at a catch-all exception handler (well, usually for Exception, not Throwable, so it's not quite catch-all) and throw a new exception, specifying the existing exception as a cuase. Traceback printing uses this information and suppresses identical parts of the call stack, which often results in fairly useful output, without resorting to more elaborate debugging mechanisms. In contrast, I'm worried that error value threading (even when done properly, not swallowing any errors) destroys potentially valuable information about the context while the stack is (manually) unwound, leaving little more than a bare error message when it's finally reported or logged. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
