#[handle_result] - consider supporting errors that are Display, not AsRef<str>

[uint]

Motivation

#852 #854
https://near.zulipchat.com/#narrow/stream/300659-Rust-.F0.9F.A6.80/topic/anyhow.3F/near/287320608

This would make the SDK more ergonomic, especially for prototyping, allowing most conventionally used error types. In particular, it would allow using something like anyhow::Error.

Benefits

• Convenient API with better support for dynamic error messages.

Drawbacks

• This looks like it will make unhappy paths more costly. The current API nudges users toward hardcoded error messages. The new one would lead to error messages that are built dynamically implicitly. Might be worthwhile to investigate if we can have contract devs opt-in to the new system, or something of the sort.

[frol]

@uint Why Display and not std::error::Error trait?

[uint]

@uint Why Display and not std::error::Error trait?

Good question.

Well, we only need it to be Display so that an error message can be produced. Requiring Error narrows the pool of types that can be used. Is there a benefit?

[frol]

Is there a benefit?

Good question. I think there is none besides just communicating the intent better.

One thing to consider is no-std mode if we ever want near-sdk-rs to support it.