Closed axelboc closed 4 months ago
Apparently, exception handling is disabled in Emscripten by default. So it might simply be a matter of compiling h5wasm with flag -fwasm-exceptions
.
By default, the HDF5 library error handler function prints to the error stream for every error. This is what is ending up in the users' console. That error handler function can be overridden, but it would require writing a new error handler function in C, and setting that as the default. There don't seem to be a lot of examples of custom error handler functions.
It's possible that the C++ API for for HDF5 has exception handling in it already - but migrating to that API from the C API would also be some work.
There is a PR brewing for raising exceptions in h5wasm here: https://github.com/usnistgov/h5wasm/pull/68 I still have to write some tests, but it seems to work as expected.
Fantastic!! Thanks for looking into this 💯
Opt-in to throwing error handler is available new release https://github.com/usnistgov/h5wasm/releases/tag/v0.7.2
Describe the bug
When h5wasm throws an error internally, for instance when reading a compressed dataset without the appropriate plugin, the error appears in the console but is not propagated to the viewer.
For compressed datasets, if we didn't throw our own error when the required compression plugins aren't available, we might not even realise the problem, since the visualization would most likely continue to work. In other cases, like with this bug report that was encountered on myHDF5, the h5wasm error causes the viewer to throw another, completely unrelated error further down the line, which can be confusing.
To Reproduce
apps/demo/src/h5wasm/plugin-utils.ts
(e.g.Zstandard
) and silence the TS error.packages/h5wasm/src/h5wasm-api.ts
(replace with early return).zstd
).Expected behaviour
When h5wasm throws an error, this error should be propagated to the viewer and trigger the visualization area's error boundary.