Comments (10)
Something like this seems ok (just a sketch), but happy to review C API design from other libraries.
struct FizzyError { int error_code; const char* message; }
FizzyError err;
fizzy_parse(..., &err);
if (err.error_code != 0)
printf("%s", err.message) && exit(err.error_code);
fizzy_instantiate(..., &err);
if (err.error_code != 0)
printf("%s", err.message) && exit(err.error_code);
fizzy_free_error(&err);
So the FizzyError
is reusable and optional (you can pass NULL
meaning I don't care about error.
from fizzy.
Can a roadmap item be added for all-around better error handling? The existing API has zero error handling, and though I'm moving to Fizzy from wasm3 due to some convoluted blocking bugs, wasm3 has much better error handling in its API that I'm really missing.
Right now, it's just "welp, it failed" if some of the resulting pointers are NULL - there's nothing to help understand why something failed.
from fizzy.
You are absolutely right. I was integrating fizzy into something else the other day and the lack of error message propagation is annoying. We'll think about a good API for this for the C layer, but if you have some ideas please do not be afraid to share them.
from fizzy.
@axic an extra parameter that accepts a pointer to an error code would be great.
Alternatively, changing the return types to be an error code (or success code of course) and having the pointer results be returned via pointer-to-pointer arguments.
For example:
FizzyModule *fz_mod;
int r = fizzy_parse(
&fz_mod,
mod_bytes.data(),
mod_bytes.size()
);
if (r != 0) {
fprintf(stderr, "error: failed to parse module: %s\n", fizzy_strerr(r));
} else {
assert(fz_mod != NULL);
/* fz_mod is valid */
}
from fizzy.
I think we want to go beyond error codes to have the capability of returning messages. While error codes work well for many cases, they do not for telling about import resolutions problems (i.e. including namespace, module, etc.)
There are two problems with returning messages though: a) who manages the memory allocated for them; b) can we avoid allocating memory.
In the following option FizzyError
is just a nice container for a fixed-size buffer. In this case the error message buffer lives on the stack of the caller:
FizzyError err;
fizzy_parse(..., &err);
... = fizzy_error_msg(&err); // returns const char *
In the following option we use a global buffer, which can be queried. The downside is that subsequent calls overwrite it and it is not thread safe.
fizzy_parse(...);
... = fizzy_error(); // returns const char*
Lastly, we return a message object which has to be explicitly free'd by the caller:
FizzyError* err;
fizzy_parse(..., &err);
... = fizzy_error_msg(err); // returns const char *
fizzy_error_free(err);
I'm sure @chfast and @gumb0 have some better ideas.
from fizzy.
@Qix- another question: should we have a public C++ API, would that be preferable? I'm not saying we'll have it anytime soon, but it is only missing due to lack of time.
from fizzy.
Yes, that matches my first idea. Though I was wondering if the struct should be opaque or not.
However, when it is reusable then subsequent users must check if err.message
is not null and free it.
from fizzy.
However, when it is reusable then subsequent users must check if
err.message
is not null and free it.
No. This can be handled inside Fizzy. Only after the last use the manual free is needed.
Alternatively, we can adopt this Store
think present in many wasm implementation, including wasm-c-api.
from fizzy.
However, when it is reusable then subsequent users must check if err.message is not null and free it.
No. This can be handled inside Fizzy. Only after the last use the manual free is needed.
My wording was unclear, by "subsequent users" I meant subsequent calls. So I agree 😉
from fizzy.
The problem with error strings is two-fold:
- They are not (easily) localizable.
- They are not guaranteed to be programmatically switchable (e.g.
if (errcode == FIZZY_ENOSUCHIMPORT) { /* ignore */ }
) even if you useextern
strings.
This is why many C libraries provide a const char * strerror(int)
function that translates error codes to statically allocated messages (e.g. POSIX C, libuv, etc.) allowing for other consumers of the library to localize if need-be.
I would recommend doing it this way.
In the event you do decide to go with strings, please under no circumstances perform an allocation. This could cause a cascade of failures that makes debugging (especially in production) very difficult (a memory error would cause a memory-related crash, masking the originating Fizzy-related error - or, many error codes could be generated that are ultimately ignored, but a forgotten free()
causes a memory leak over time, etc.)
Any error-related strings should be strictly statically allocated.
from fizzy.
Related Issues (20)
- Add PGO builds HOT 2
- Optimize UTF-8 validation
- Add upstream WASI tests
- Exceptions don't propagate back up through the runtime HOT 2
- CNCF SIG-Runtime Discussion/Presentation?
- Add benchmarking case using evmone
- Create header-only helper library (easel)
- Fuzz against wasmtime
- Add Go configuration for lgtm
- Add Java configuration for lgtm
- Add Python configuration for lgtm
- Support the entire WASI specification
- Fix macOS compilation for fizzy-unittests for floating points
- Does fizzy have any plans to support fix-width SIMD? HOT 2
- Move to C++20 as minimum requirement HOT 1
- Update Xcode on CI to newer version
- Update gcc on CI to newer version
- Improve wat2wasm4tests to return error code on more failures
- JavaScript binding
- No instructions for using fizzy
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fizzy.