Proposal/Question: changing cause of an err

[dvic]

What is you opinion on having the ability to wrap an existing error instead of a message and thereby also changing the cause of the returned error? Something along the lines of wat juju/errors is doing:

func Wrap(other, newDescriptive error) error { ... }

Example usage: you receive a strconv.NumError but you don't want to return it directly: you want to wrap it into an error that implements, e.g., InvalidRequestDetails() (bool, map[string]string) (this is where I see the need to change the cause, but please correct me if I'm wrong).

Thank you for your time!

[davecheney]

Thank you for raising this issue. I have two comments on this

1. the first is I'm not keen on adding an API which takes two parameters of the same type, experience shows that there is a 50% chance of getting it wrong, especially as error paths are commonly undertested.

2. If you want to change an error from one cause to another; why not just return the new error instead? What about the original error do you wish to retain? Its stack trace? and wrapping's between the point where it was generated and where you wish to replace it?

[dvic]

Good point on avoiding methods having two parameters of the same type. I could just return the new error instead, but it would indeed be nice if the stack trace and maybe some structural details of the error were preserved (so that, for example, logging middleware could pick this up and log it how it sees fit). For now, I'll just stick to including the message of the wrapped in the Wrap(err, message) call. Thanks!