Question: Obtaining the original cause

[johngb]

I have been using this package for a while now without any problems (I love it). However, today I came across a behaviour in my code that I can't understand when trying compare the result of errors.Cause with a named error. I've read through the documentation, and I came across the following statement:

Depending on the nature of the error it may be necessary to reverse the operation of errors.Wrap to retrieve the original error for inspection.

1. In which situations is it necessary to reverse the operation of errors.Wrap to inspect the original error?
2. How does one reverse the operation of errors.Wrap to obtain the original error?

[pierrre]

How does one reverse the operation of errors.Wrap to obtain the original error?

https://github.com/pkg/errors#retrieving-the-cause-of-an-error

[johngb]

@pierrre I asked because I had a case where errors.Cause was returning an error which when compared to the original named error in a package did not evaluate as equal.

We've subsequently worked around the issue by comparing the err.Error() string for each instead, but the problem was perplexing.

[pierrre]

where errors.Cause was returning an error which when compared to the original named error in a package did not evaluate as equal

Why aren't they equal ?
Did you inspect the error values with fmt.Printf("%#v", err) ?

[johngb]

Why aren't they equal ?

I wish I knew. From everything that I understand, they should be, but for some unknown reason weren't evaluating as equal.

Did you inspect the error values with fmt.Printf("%#v", err) ?

No, I didn't, but in hindsight I should have. For logistical reasons it may not be feasible for me to roll back the project to test this out, but I'll do my best to compare them this week.

[LasTshaMAN]

@johngb Any followup on this ?