Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error Handling #7

Closed
raquo opened this issue Sep 9, 2018 · 3 comments
Closed

Error Handling #7

raquo opened this issue Sep 9, 2018 · 3 comments
Labels

Comments

@raquo
Copy link
Owner

raquo commented Sep 9, 2018

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)

@raquo raquo added enhancement New feature or request hard problem labels Sep 9, 2018
@fdietze
Copy link

fdietze commented Sep 10, 2018

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
Copy link
Owner Author

raquo commented Sep 10, 2018

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
Copy link
Owner Author

raquo commented Oct 2, 2018

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.

@raquo raquo mentioned this issue Oct 14, 2018
3 tasks
@raquo raquo closed this as completed in #11 Nov 4, 2018
@raquo raquo added the design label Sep 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants