davecheney
commented
6 years ago The intention is you start with your own error type which implements the behaviour you want to assert for, then use Wrap or With to annotate it during the error path, at the point you want to test for the original behaviour, use cause to undo all those layers of annotations and recover the original error.
On 19 Jul 2018, at 07:18, Nathaniel Tucker notifications@github.com wrote:
In https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully there is talk about having interfaces for certain types of checks, but how does one actually build a new error with these interfaces and also use the cool error types provided here?
One might think composing the types would work, but this package doesn't make its types public.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
ntucker
In https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully there is talk about having interfaces for certain types of checks, but how does one actually build a new error with these interfaces and also use the cool error types provided here?
One might think composing the types would work, but this package doesn't make its types public.