Open fibonacci1729 opened 3 months ago
I would definitely prefer its own interface if possible in the options you presented, but I am also rather partial to errors being represented as enums rather than opaque resources. Was thinking about changing that as part of an upcoming PR to integrate some feedback from people
Heads up @fibonacci1729 that I added error as a variant in #23
As a bit of early implementation feedback, i found that implementing the host side of things for
wasi:messaging/messaging-types/error
imposed a bit of a hurdle/challenge.How would everyone feel to replace the custom error resource defined in this package with wasi:io/error/error.
Alternatively, to make host-side implementations easier to wrangle, i'd suggest isolating out the error type into its own interface (similar to
wasi:io
s error) which would minimize the host code required.Wdyt?