Improve error messages to point to error source

[felipemadero]

Goal

Following suggestion at #2440

Either add a trace, line number, or function name, what is needed so the error can be trace back to
the origin (at least under CLI).

The issue is created so 2440 can be closed with the proper functionality fix.

User suggestion:

I would also point out we should have better error wrappings in calling layers if the error is not nil, since right now I'm quite confused where this error came from in the process (no call stack or source file line number either).

Assumptions and Scope

Example Usage

Requirements:

Current Limitations

Nice to Have, but Not Required

Open Questions

[qdm12]

If I may, I would recommend to have just human text strings wrapping errors, either with fmt.Errorf("doing xyz: %s", err) or fmt.Errorf("doing xyz: %w", err), such that:

• it does explain to the non-developer user what went wrong better
• it allows the developer to pinpoint relatively quickly where this error is coming from

Traces, line numbers, file names and/or function names tend to make logs rather horrible to read, I would not do this personally and prefer wrapping errors. Obviously, having a filename+line number could be a nice band-aid fix in the meantime, let's face it 😉