Hi everyone,
I am in the process of creating a react-three-fiber (three 0.135.0) app, where users given ability to provide *.exr images for use in app. Of course, ‘three/examples/jsm/loaders/EXRLoader.js’ loader is used to create a texture from provided image file.
If provided image has supported settings, everything works as expected, but if EXR file contains data of an unsupported format, THREE throws following error.
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'length') at eval (three.module.js:38920)
I added two consoles to three.module.js in order to show you some values. And here is where actual error of reading properties from undefined occurs (original line is 38920).
As you can see, this happens directly in the .catch block, so, of course, I can’t catch this error from the outside, because THREE modules are not under my control.
I tried to use both .loadAsync() and .load() with .catch() and onError callback respectively. But this did not make much sense, because, as far as I understand, the error occurred during onProgress stage (rather during process of reading data), just before calling an actual error handler.
For the sake of the experiment, I tried to use latest version of THREE 0.136.0. It provides a little more information, but with the same result eventually.
Luckily, React keeps everything in the states, so an uncaught error in THREE does not break my app and that uncaught error goes unnoticed by the end user (although the production dev. tools console still shows an error).
I came up with not a solution, but rather a patch. In particular, I put a clear and set timeout into onProgress callback with a second delay. Each time onProgress is fire, it clears previous timeout and releases a new one with a callback that contains expected response to the error. When an actual error occurs, nothing clears onProgress timeout, and I get a response to the error immediately second later this way. In my case, the reaction is very simple, I remove “Loading…” spinner from the screen and show “unsupported format” messages to end user.
The problem is not that the current EXRLoader does not support some EXR encoding (or something else…), the problem is that it gives an error that cannot be caught in any way, which definitely disrupts linear flow of the program pipeline.
The patch works well for me, but it’s not exactly the way it should be.
I must say that I am a complete new to THREE. This is my first app with it, so I am well realize that it may be my fault and that I did something wrong, but so far I can not figure out what exactly.
Thanks in advance for any help or opinions!