-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error codes from filesystem functions #555
Comments
I personally like the idea of having an error code consistency across runtimes/platforms, as that truly enables us to "write once, run everywhere" in the WASI world. Whereas there are cases where error codes are just for logging / debugging purpose, there are cases where they are actionable and code can rely on them. Having said that, I do agree they introduce quite a bit of overhead in terms of documentation, so we'd need to do some incremental work to update all of that. I'm curious what approach is planned for preview2 interfaces - is there going to be a list of error codes for each function (e.g. filesystem, cc: @sunfishcode )? |
I agree with the idea of being consistent, but I wonder if this error code problem goes away due to using WIT to define preview2. Previously we had to share an error code space among many functions; now each function can return its own error enum that only contains the applicable error cases. |
I also agree this would be nice to do. If anyone is interested, I guess the first step is to start making lists of errors for each function. |
i guess it won't go away as far as we will support some mappings to posix api. |
While attempting to fix the rust WASI tests on WAMR, I ran into various discrepancies between the expected error codes for various filesystem operations and the expected error codes (presumably suited for wasmtime).
Since we don't seem to document the returned error codes for the filesystem functions, I was wondering whether we should? If we don't want to explicitly document every error code for each condition, defaulting to POSIX might be another option. But I'm not sure if this is
a) useful
b) overly restrictive
Any thoughts or suggestions would be appreciated, thanks!
The text was updated successfully, but these errors were encountered: