Naturally, as with most worker-type applications, error handling is centralized, meaning not done during the command execution itself, but through a separate error handler. The problem with that is that you often lose important debugging information. Even if you have a fancy logger that shows you file and line, it will be of little use if your error is handled centrally.
Luckily, adam circumvents this problem by attaching stack traces where needed. This means, that you can later utilize this information to trace the error to its source. These stack traces are available through the StackTrace method, which has the same signature as the errors generated by github.com/pkg/errors, meaning it is supported by error handling tools such as sentry (The signature is the same when using reflect, as sentry does. Type assertions on adam's errors that expect github.com/pkg/errors' StackTrace method signature will fail).
Instead of doing your usual return err, return with return errors.WithStack(err). This will add a stack trace to the error, starting at the line of the return. If you call functions provided by adam, you don't even need to do this as adam already returns errors enriched with stack traces.
However, not always does an error mean something went wrong. Sometimes the error is on the user's side and you want to communicate that to them. For cases like those, adam provides different error types apart from the *errors.InternalError generated by errors.WithStack. Head over to the next page to learn more.