You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present when raising an error in the guest we are using a generic HyperlightGuestError variant, it should be possible for a hyperlight implementation to define their own error variants.
These variants should be transparently translated between guest and host, in other words if a guest returns Err(ParseError) then the result of the call in the host should be Err(ParseError)
There are two parts to solving this issue:
(1) Being able to create specific types of Hyperlight guest errors (i.e., similar to thiserror in the host),
(2) Type information of the guest error in the host would get lost without (1).
Note that thiserror now supports no_std.
The text was updated successfully, but these errors were encountered:
At present when raising an error in the guest we are using a generic HyperlightGuestError variant, it should be possible for a hyperlight implementation to define their own error variants.
These variants should be transparently translated between guest and host, in other words if a guest returns Err(ParseError) then the result of the call in the host should be Err(ParseError)
There are two parts to solving this issue:
(1) Being able to create specific types of Hyperlight guest errors (i.e., similar to thiserror in the host),
(2) Type information of the guest error in the host would get lost without (1).
Note that
thiserror
now supportsno_std
.The text was updated successfully, but these errors were encountered: