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
Currently the C API provides no means of communicating rich error information (e.g. strings/class/code/etc) which isn't a trap. For example wasm_module_validate only allows returning a bool whereas engines probably have more rich information such as a string and an offset the error applies to. For an embedding using the C API it's often critical to end-users to be able to see what went wrong when something goes wrong, so it would be nice to have the ability to thread through this information.
Depending on the outcome of #132 this may also apply to many other APIs as well. For example wasm_instance_new could fail for a whole host of reasons (such as link errors), and it will be useful to communicate this to callers.
For now I think a string (wrapped up in a new error type) is good enough, but this also provides a location for future improvements, such as getting the error offset into the wasm binary for validation, for example.
The text was updated successfully, but these errors were encountered:
Currently the C API provides no means of communicating rich error information (e.g. strings/class/code/etc) which isn't a trap. For example
wasm_module_validate
only allows returning abool
whereas engines probably have more rich information such as a string and an offset the error applies to. For an embedding using the C API it's often critical to end-users to be able to see what went wrong when something goes wrong, so it would be nice to have the ability to thread through this information.Depending on the outcome of #132 this may also apply to many other APIs as well. For example
wasm_instance_new
could fail for a whole host of reasons (such as link errors), and it will be useful to communicate this to callers.For now I think a string (wrapped up in a new error type) is good enough, but this also provides a location for future improvements, such as getting the error offset into the wasm binary for validation, for example.
The text was updated successfully, but these errors were encountered: