Consider replacing `String` errors with `anyhow::Error` in interfaces

[hashedone]

I understand, that using generic errors is easier for interfacing than custom errors, and probably good enough, however using Strings makes it kind of strange for testing and debugging, as it looses most of relevant information. I think that using anyhow would be as good as String, and would allow for more precise testing (instead of checking string value which is never good as slight changes affects it, such errors could be downcasted), and also have better feedback on failures.

The most problem I see with that, is breaking all the APIs and I am not sure if it is not too late for such a change.

[ethanfrey]

The most problem I see with that, is breaking all the APIs and I am not sure if it is not too late for such a change.

multi-test has never been promoted or published and anyone using it outside of our internal tooling is using it at their own risk. Either the 0.8.x or the 0.9.x series, I would like to start promising stability, but now is the time to break those multi-test APIs.

I think that using anyhow would be as good as String, and would allow for more precise testing

I used String for 2 reasons:

• It allowed me to convert all the various custom error types into one standard
• This is what is done between contracts when we go through wasmd

The first point is well handled with anyhow and much nicer actually.

The second point, I am unsure, please investigate. A contract can directly return an anyhow error to the caller. Great. But if a sub message returns that, it still needs to convert it into a string for the reply block. If you have a proposal such that reply still gets the expected strings, that I am happy to use this as a better API

[hashedone]

Regarding second point, directly from anyhow documentation (I was pretty sure it was this way, but double checked):

When you print an error object using “{}” or to_string(), only the outermost underlying error or context is printed, not any of the lower level causes. This is exactly as if you had called the Display impl of the error from which you constructed your anyhow::Error.

So effectively if you are not using context (which is not important), Display of anyhow::Error just evaluates to Display of error you assigned - without any history (completely ignoring the cause if any). So assuming you create actual error types as thiserror errors, so you can easily create reasonable messages (and if really want - unit test it on this level so you are warned when they change), and then just populate them as anyhow so you don't care too much about exact error type.

[ethanfrey]

Sounds good.
I would not include this in 0.8, but we can do that shortly afterwards