Consider adding FromString/FromJSON methods

[ericschmar]

Is your feature request related to a problem? Please describe. I'm using a message queue that utilizes gob/encoding for encoding arbitrary data into messages. I have messages that need to persist errors between various points of interaction. I would like a simple way of including errors in this, while maintaining all the stack traces and various benefits eris provides.

Describe the solution you'd like Provide a companion API to eris.ToJSON and eris.ToString (or at least just JSON). Ideally, these functions would take the output of eris.ToJSON and when passed into the new eris.FromJSON, we get back an error (that implements the interface) and has all the relevant stack/external info from wrapping errors.

Alternatively, you could add a companion method to eris.Unpack called eris.Pack that would take an UnpackedError and return a regular error, again keeping all the information.

Describe alternatives you've considered Manually JSON encoding/decoding, however after crossing this boundary, no code can access the eris functions like eris.Cause, which are very useful for unwrapping.

Thanks for considering.

[morningvera]

Hey @ericschmar, I like this idea! Let me think about it for a bit. I’ll open a PR once I figure out the best approach. Thanks for opening this issue!

[ericschmar]

Hey @ericschmar, I like this idea! Let me think about it for a bit. I’ll open a PR once I figure out the best approach. Thanks for opening this issue!

Awesome. I worry about maintaining the stack trace as it stands currently in the code base (it's using pointers to actual memory locations, as opposed to like an array of strings or something simple). But in either case, I think that adding this form of marshaling would put this library above a lot of other error libraries.