ErrDying and errors.Trace()

[Gustavo Niemeyer]

Hi John,

On Thu, Apr 2, 2015 at 8:44 AM, John Meinel <john at arbash-meinel.com> wrote:
>
> All of which seems pretty standard. If we find out we are dying while we
> are trying to do something else, return ErrDying. When that bubbles up to
> the top, we just call tomb.Kill() with any error that we got so that if we
> got a genuine error, a future worker.Wait()/Stop() call can return the
> actual error.
>

Right, pretty standard use of tomb.


> And what is happening is that because of the errors.Trace() we aren't
> handing it ErrDying the singleton error instance, we are handing it an
> errors.Err{Cause: tomb.ErrDying}
> Which then when we check "worker.Stop() error" we get a real error instead
> of nil.
>

There's another bad side effect of that wrapping: it will hide actual
errors. The ErrDying error value preserves the tomb clean, so that if some
piece of code has an actual error to report, it will be tracked. When the
logic taints the tomb with an irrelevant error all the time, actual errors
won't get in.


So for now, I decided to trap in NewTrackerWorker and if we have an
> errors.Cause() of ErrDying we unwrap it before passing it to tomb.Kill().
>
> If we want to be using errors.Trace more (and it certainly was nice to
> have at least some sort of traceback to figure out where these steps were
> occurring), shouldn't we be updating our general pattern?
>
> Do we have to wrap every call to tomb.Kill(err) with
> tomb.Kill(OnlyRealErrors(err)) ?
>

Perhaps yourutils.KillTomb(tomb, err)


> Should we (can we?) teach tomb about the errors package so that it can do
> its own unwrapping?
>

For now, it sounds very specific to that environment, so I'd prefer to put
the burden on the side that is introducing that complexity.


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150402/a2217299/attachment.html>