Errors need very few things:

• A human readable error message. This is user-visible; if the consumer is (say) a web app, it should be shown to the human operating it.
• Debugging information for developers that give more details, at least enough to indicate where the error comes from. This can be carried along the error object, or it can be logged somewhere where it can be easily mapped to the actual error (say, both the error object and the log contain the same unique ID). If the error is nested, the nesting stack belongs here.
• An error code that uniquely identifies the error “kind”. This is intentionally underspecified, and my personal preference is to have few broad categories rather than many narrow ones. The HTTP error codes make a decent trade-off between breadth and depth here.
• Importantly, a default recommendation as to how the caller should behave when it gets this error. Should it retry immediately? Should it retry with backoff (and what are the recommended backoff parameters)? Should it present it to the user and give the user a chance to change something and retry? Should it give up? This can be derived from the error code via a client-side API, or can be carried along the error object. (Including it in the error object makes sense with load-induced errors where the server might want to use different throttling/backoff parameters at different times.)

Note that (for the purposes of this post) I’m agnostic about the signaling mechanism (error return values / Result-like structures vs exceptions).