new dependency

[Nate Finch]

On Fri, Feb 7, 2014 at 5:24 AM, roger peppe <rogpeppe at gmail.com> wrote:

>
> http://play.golang.org/p/Ze_YTCcfzm
>
> Note that, even ignoring the doc comment, it is easy to tell by
> looking at the high
> level function, ReadPacketFromNetwork, what classifiable errors might
> be returned from
> it. This makes it easy to write the doc comment - the contract with the
> caller is clear.
>

This seems to be where we're differing.  I'd never return io.UnexpectedEOF.
 I'd return a custom error like mypackage.TruncatedData.

So then the calling code would look something like this:

http://play.golang.org/p/kAWClCm3gv

(that's using a testing function, you could instead let the caller do a
type check, but that's uglier).

UnexpectedEOF is an implementation detail. It's the package's job to
translate that into something the caller can understand, and hide the
implementation from the caller.  What if you change the code later so it
calls something that doesn't return UnexpectedEOF?

If they really really want to look at the underlying error, they could get
the cause from the TruncatedData error, and see it's UnexpectedEOF.... but
we can say that that's not something you'd ever want to rely on, and I
can't imagine anyone actually caring.

This, then, is the essence of the distinction between Diagnosis and
> Cause - the Diagnosis is part of the contract of a function - it is
> something that a caller may depend on and that it is the responsibility
> of a function to maintain. The Cause is just some arbitrary underlying
> error - there are many possible error causes, but we don't want arbitrary
> calling code to become dependent on them, because every error cause
> reflects some implementation detail, and depending on implementation
> details makes the code base more brittle and harder to change.
>
>
I guess I don't understand why you'd ever want a diagnosis that's different
from just the error you're returning.


> > I'd like to then steal arrar's function for returning a list of the
> > underlying errors (GetErrorStack), and I like his string formatting
> better
> > for the stack-trace-lite (DetailedErrorStack), but I wouldn't bother with
> > formatting parameter, because I honestly will never care.
>
> I deliberately made the error info formatting fit on a single line
> so it would work well in log files, but it would be easy to implement
> an alternative format too.


Yeah, I guess sometimes you want one line and sometimes you want multiple.
I'm just used to stack traces being multiple lines.



> > However, I also was an honest-to-god stacktrace available from the root
> > error, because both implementations can miss important information about
> how
> > you got to the root error that a real stacktrace wouldn't miss.
>
> I'd be interested to see an example of when you think the errgo/arrar
> approach would not produce sufficient information (assuming that
> errors are Traced/Wrapped by default).


See, that's the problem, assuming we always always always wrap.  If you
just slap a stack trace on the error at first wrap, you can then pass that
error back up as much as you want and not have to wrap in every single
function call.


> The honest-to-god stack trace
> is unfortunately insufficient in a concurrent world where errors may be
> (and often are) transferred between goroutines.
>

You can always add on to the stack trace when an error cross goroutine
boundaries.  I haven't really thought about it, so I'm not sure if you'd
end up with something really illegible or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140207/4e00985c/attachment.html>