emscripten-core / emscripten-core/emscripten

worker.js to catch importScripts() errors

Open
#17,562 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
27.6k
Forks
3.6k
Avg merge
1d 1h
Merged PRs (30d)
105

Description

**Version of emscripten/emsdk:**
3.1.17

Legend of my case:

```
app.html
opens app.js Worker (custom code) which executes createMyModule() and
opens myModule.js Worker (code by emscripten)
which opens many myModule.worker.js (code by emscripten)
```

In my app, user can terminate the app.js (parent worker) at any moment, and in some cases this happens very early during worker initialization resulting in myModule.worker.js throwing the following error:

```
myModule.worker.js:1 worker.js onmessage() captured an uncaught exception: NetworkError: Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at 'https://xyz/myModule.js' failed to load.
threadPrintErr @ myModule.worker.js:1
self.onmessage @ myModule.worker.js:1
myModule.worker.js:1 Error: Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at 'https://xyz/myModule.js' failed to load.
at self.onmessage (myModule.worker.js:1:829)
```

(the error code is 19 and name "NetworkError", I tried to research the code but not much details available from [DOMException](https://developer.mozilla.org/en-US/docs/Web/API/DOMException))

I managed to track it down to [line 172](https://github.com/emscripten-core/emscripten/blob/ca517661ddda2d4a730cb032ff917a299c5a4c98/src/worker.js#L172) throwing exception catched by [line 292](https://github.com/emscripten-core/emscripten/blob/ca517661ddda2d4a730cb032ff917a299c5a4c98/src/worker.js#L292) and eventually calling [line 74](https://github.com/emscripten-core/emscripten/blob/ca517661ddda2d4a730cb032ff917a299c5a4c98/src/worker.js#L74). Process ends with writing an error into the console although no harm is being done as the top most parent worker has been terminated already.

Unfortunately, I am unable to reproduce it outside of my large app.

I wonder if you can think of any elegant way to avoid polluting console with such errors from within terminated/closed workers.

Should we wrap the line 172 with yet additional try/catch to consume such errors and short circuit further execution?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.