Intelligent errors.Cause()

[jaekwon]

When causer.Cause() returns nil or itself, it is the cause.

Ref: #89

[davecheney]

Thank you for raising this PR. I'd like to take some time to understand how this could change the behavior of existing users of this package. I would appreciate it if you can help me understand, on pkg#89, not this PR, your use case, and why this change is necessary, and could your requirement be handled without changing the operation of Cause?

…

On Thu, Dec 21, 2017 at 9:49 PM, Jae Kwon ***@***.***> wrote: When causer.Cause() returns nil or itself, it is the cause. Ref: pkg#89 <#89> ------------------------------ You can view, comment on, or merge this pull request online at: #143 Commit Summary - Intelligent errors.Cause() File Changes - *M* errors.go <https://github.com/pkg/errors/pull/143/files#diff-0> (18) Patch Links: - https://github.com/pkg/errors/pull/143.patch - https://github.com/pkg/errors/pull/143.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#143>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA8drauJ4o8-YDrqCdxTRNCLSNgliks5tCjfSgaJpZM4RJp7b> .

[jjeffery]

I recently ran into an issue that this PR would resolve. I was using the popular github.com/gorilla/securecookie package. This package exports an Error type that implements the causer interface. (See http://www.gorillatoolkit.org/pkg/securecookie#Error).

It turns out that the Cause method can return a nil. This caused me problems, because errors.Cause(err) would return nil for a non-nil err.

While I understand the need to think through the implications of changing the behaviour of errors.Cause, I can't help feeling that there should be a guarantee that errors.Cause should return non-nil when it is passed a non-nil argument.

Thanks

[gregwebs]

I believe that we accidentally (this is definitely a bug as indicated by the docs) fixed this on our fork