How should error handlers treat Fatal errors?

[ajaychandran]

As per Scala JS semantics,

UndefinedBehaviorErrors are fatal in the sense that they are not matched by case NonFatal(e) handlers. This makes sure that they always crash your program as early as possible, so that you can detect and fix the bug. It is never OK to catch an UndefinedBehaviorError (other than in a testing framework), since that means your program will behave differently in fullLinkJS stage than in fastLinkJS.

Does this imply that error handlers such as the one in EventStream.fireValue should be modified to handle only NonFatal errors?

[ajaychandran]

Note that Try.apply checks for non-fatal exceptions.

[raquo]

Hm, now that you mention it, it does sound like all our error checks should only match non fatal errors. That's what Monix seems to do for example.

Aside from UndefinedBehaviorError, I'm not sure if there are any special scala.js considerations for handling NonFatal errors (plain JS has no observable concept of special fatal errors as far as I know).

[ajaychandran]

I am not even sure if UndefinedBehaviorError exists. I could not find it using Intellij search.
The ZIO runtime has a guard only for the JVM platform, and not for JS.

The Scala JS documentation also states

Some of these, however, can be configured to be compliant with the JVM specification using sbt settings. Currently, only ClassCastExceptions (thrown by invalid asInstanceOf calls) and ArrayIndexOutOfBoundsExceptions (thrown by array indexing) are configurable, but the list will probably expand in future versions.

This leads me to believe that we should check for NonFatal exceptions.

[raquo]

UndefinedBehaviorError certainly exists, you can get it in fastOpt when e.g. you call def foo: String = js.native on a JS interface, but that method returns js.undefined instead.

This leads me to believe that we should check for NonFatal exceptions.

Do you mean because of "the list will probably expand in future versions" part? Because the two mentioned exceptions are regular runtime exceptions, not fatal.

I wonder why ZIO behaves that way. Maybe they're onto something. The canonical argument for only catching NonFatal exceptions is to let the program crash and burn, but with asynchronous programming in JS "crash and burn" just means that the currently executing "message" (in event loop terms) will terminate. This will cause window.onerror to emit the exception, but the program will resume just fine after that, except because the fatal error wasn't handled, airstream's internals will now be in an inconsistent state.

I'm not sure what's the right thing to do in scala.js. Current situation is not great because Scala's try-catch behaviour is inconsistent with Try-s, and we use both, but if we're going to change Airstream behaviour, we should make sure to move into the right direction, whatever that is.

[ajaychandran]

Do you mean because of "the list will probably expand in future versions" part?

Yes.

We can keep the issue open for now.