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 https://github.com/WebAssembly/wasm-c-api/issues/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.
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_validateonly allows returning aboolwhereas 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 https://github.com/WebAssembly/wasm-c-api/issues/132 this may also apply to many other APIs as well. For example
wasm_instance_newcould 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.