I have used this {:error, exception_struct} approach to good effect in an order processing system. Not only could I have a field in the exception struct to specify the “step” of order processing that failed, but the exception module itself served as a nice place for a mitigate function to centralize knowledge of what can be retried, what should just be logged, what should go into a manual human-monitored error queue, etc.

Do you want the small error details at your application level or logging? There are big differences and implications between one or the other. If you are trying to write defensive code that handles all errors at application layer, then you will not have many tools to help you out, as that opposes the idea of OTP to let it crash.

If we are talking about logging, then this problem is already solved. The logger formatter allows to specify your custom format of the logs. The great additional feature it has it’s called metadata:

$metadata - user controlled data presented in "key=val key2=val2 " format

In your codebase you can use Logger.metadata/1 to set all the custom metadata you might require when something gets logged, the great thing is that this is also automatically applied to when errors are logged, so you basically don’t have to do anything custom.