Error Handling

[raquo]

As documented, currently an exception thrown anywhere in observables or observers is undefined behaviour. Obviously this is a non-starter for any production application, so the next version of Airstream will include error handling.

I haven't thought much about the specifics, so no special design decisions just yet, but in broad strokes I think it'll look something like this:

• the failure in an observable can be recovered from using methods like recover(err => value)
• the failure should be toxic (if unhandled, dependent observables should fail as well)
  • All of them, or just some? Does e.g. EventBus need an ErrorHandlingStrategy param?
• observers should be notified of errors with an optional onError
• it should be possible to print out all unhandled errors to dev console. Maybe a global stream exposing unhandled errors?

I will consider introducing observable completion at the same time, but no promises that I'll decide to implement it (see #1)

[fdietze]

I think for errors it is important that the stack-trace is somehow readable. Working with scala.rx and Monix it was sometimes difficult to find out where the error originally came from.

[raquo]

Considering stream.map(project), if project throws, I expect to be passing the same exception to all relevant onError handlers. This would mean that the last line in the stack trace should point to the place in project where the error was triggered.

I haven't worked much with either Monix or scala.rx, don't they give you something similar?

[raquo]

Regarding observables completion feature, I was recently thinking more about it while working on this, and another obvious-in-retrospect issue with it is that it's only really applicable to streams.

An EventStream that is complete is done with life. It can release all references it's holding as it will never emit again, and will thus never affect anything else in the program. A Signal or State variable on the other hand, can not really enter such a "completed" state. It still needs to hold a reference to its current value at all times, as other parts of the program, including but not limited to dependent observables could need it for their calculations.

This kinda ties into how streaming libraries like RX / monix deal with errored streams – these streams simply "complete". On the other hand, scala.rx, being a state propagation rather than event streaming library, treats exceptions much more similar to how they are treated in plain Scala, making failed observables toxic to their dependencies.

The errors in scala.rx propagate to their consumers like exceptions propagate up the call stack, but in RX / monix they do not. You just get a broken ("complete") stream with no means to make it work again unless you can create a copy/replacement of it – but if you do that, you could have also prevented the error in the first place, using an error value instead of an exception. The whole point of exceptions is being able to handle them "up the stack" ("down the dependency tree" in our case) where you might not have access to the necessary stream creation logic. Imagine if every function that threw an exception became inoperational from that point on, requiring a replacement function to be provided to be called again. This is what typical streaming library error handling is like, and I'm not feeling the rationale for such weirdness. So I'm going in the general direction of what scala.rx is doing, for all kinds of observables.