I like error wrapping. I've worked in codebases where systems had to be debugged by piecing together individual log lines. With error wrapping I can usually see the exact path that lead to the error in one line.
I like error wrapping. I've worked in codebases where systems had to be debugged by piecing together individual log lines. With error wrapping I can usually see the exact path that lead to the error in one line.
That way you’d be able to trace the stack of functions that were involved in passing an error back up to the place where it’s actually handled.
This is called a stack trace, and I agree it can be very useful (if the developers were thoughtful about their error handling)
Agreed. How I articulate it, often a function is just another layer, does one core thing and one-two extras. I wrap meticulously the errors of the extras. The core errors mainly speak for themselves, so they rarely need any wrapping.
Avoids:
cannot load config: cannot load config: cannot load config: file not found
But promotes: cannot load config: cannot connect to Configurer: loading client cert: PEM invalid
The latter case reads like a list of plot twists, because it is one. A corresponding 40-line stack trace might be less readable.In my experience it's usually useful though, it usually tells you both what the problem is and where it is. Sadly a lot of people just don't even try to read them.