Unhandled exceptions

[tve]

I've now had an unhandled exception several times and it's always a bit of a goose chase.
In xsbug all I see is

XS abort: unhandled exception

If I add a try-catch in the right place I can print the error text. Questions:

• why does the XS error handler not print the specific exception text?
• can I catch unhandled exceptions globally so I can print all the info myself?
• if I load a mod and the unhandled exception happens there, can I catch it so I can decide what to do in the host?
• if it's impossible to intercept the exception and halting of the program, can I configure XS to reset or do I have to use a watchdog-reset for that?

[phoddie]

I've now had an unhandled exception several times and it's always a bit of a goose chase.

By default, xsbug breaks on exceptions. That shows the line of code where the exception occurred, the stack trace, and allows you to inspect variations in each stack frame. By default, xsbug breaks on exceptions. Perhaps you disabled it?

The behavior of unhandled exceptions is not specified by the JavaScript language. Each runtime is free to implement the behavior it believes best. The Moddable SDK chooses to exit the process on unhandled exceptions because it is the safest default behavior.

XS itself does not decide what to do in response to exceptions and other potentially fatal exceptions. Instead, it calls the host's fxAbort C function to decide. Some deployments using XS and the Moddable SDK change that behavior.

[tve]

The "break on exceptions" switch is only really useful if the exception happens right at start-up or if the app does not throw exceptions during normal operation. I had it turned off due to the latter issue. It would still be nice for the exception handler to print the exception but I guess I'll have to implement that myself.

[tve]

BTW, could xsbug have a "break on unhandled exception" option?

[phoddie]

In theory, of course. But that would be the long way around. xsbug only knows there is a breakpoint, not the cause. So the protocol could need to be extended to allow that information to propagate, each host updated to send it, and then xsbug updated to use it. Or the host could trace that information itself from the host, which is what is described above.

[phoddie]

The "break on exceptions" switch is only really useful if the exception happens right at start-up or if the app does not throw exceptions during normal operation. I had it turned off due to the latter issue. It would still be nice for the exception handler to print the exception but I guess I'll have to implement that myself.

You might reconsider designing code that "throw[s] during normal operation." Engines generally can't/don't optimize try/catch and, as you have experienced, all those exceptions can get in the way.