propagateExceptionFinalResort implementation for wasm-js and js confusing users

[bashor]

Both implementations call console.error and pass exception.toString(), which is basically a name of Exception class + message. In addition, console.error prints a stack trace from a call site (not from the exception!!), which users often consider a stack trace from the exception (example).

In this project, you can find a project with a simple repro and possible improvements implemented via CoroutineExceptionHandler.

I think #1 or any other way to rethrow the exception is the best option since there are standard ways inside JS runtimes to process unhandled exceptions. These might be used directly or by some library intended to handle problems on a page. In the worst case, a browser (runtime) will show the error in a standard and more convenient way.

[bashor]

Here is what it looks like
For Wasm

For JS

[bashor]

Possible improvements

Wasm

JS

[dkhalanskyjb]

(Other examples of people, including me, being confused: #4213)

Yes, thanks, this would be a welcome change. After some research, it looks like the setTimeout approach is the most idiomatic one, and it does fulfill the requirement of being a last-resort exception propagation mechanism: running setTimeout(function() { throw new Error("Crash"); }, 10000) in my browser, I do see the exception with the stack trace, and it looks like Node.JS crashes the application in this scenario, just like we do on Native and on Android, unless the unhandledrejection handler is set: https://stackoverflow.com/questions/74791016/node-js-unhandledrejection-with-async-function-calls-that-are-not-awaited . On the non-Android JVM, we also respect the installed https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html, so this is completely consistent.

Would you like to make a pull request with this change?

[bashor]

Would you like to make a pull request with this change?

Not anytime soon, so I'd appreciate it if someone could take it and fix it.