One problem I often encounter, are errors without any context.
If an arbitrary method returns an error "invalid character '}' after object key", you will have to dive down the stack until you find
the exact place the error happened. Therefore whenever you receive an error and you decide to not handle it, but instead
return it to the caller of your method, you should provide context about the reason the error occurred.
Let's take the following method as example:
If serviceA or serviceB returns an error, we don't know which one failed and we don't know wether it is our fault
or maybe the service is unreachable or misconfigured?
The error could look like this:
By wrapping the error, we can provide the missing information about what part failed:
The result would be unambigous:
In this simple example the advantage is not crystal clear. But imagine serviceA is doing a complex task itself and doesn't wrap it's error as well.
You could end up getting generic errors (e.g. a timeout on an http call) and need to debug down the whole stack to find out which
call has failed. But if errors are always wrapped with necessary context, an error message could look as nice as this:
Therefore if you decide to bubble up an error, always provide context.