Comments (3)
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.
from airstream.
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?
from airstream.
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.
from airstream.
Related Issues (20)
- .split operator is hard to use without Laminar
- Killing subscriptions from observers (?)
- splitByType / splitByEnum HOT 6
- Can `DerivedVar` support `map/update` semantics in addition to `map/contramap` semantics? HOT 2
- Add an AjaxStream upload progress observer
- FetchStream does not emit events if it's initialized outside of a transaction HOT 1
- How to use or override protected[airstream] members when extending observables?
- Regarding Functional Reactive Programming HOT 3
- Add splitByIndex HOT 3
- Side effects in functions passed to operators HOT 1
- Semantics of `toSignal` HOT 1
- Sampling a signal shouldn't cause the overhead of observers HOT 1
- Documentation: Observers Feeding into Var HOT 5
- Var: batch set regression in 0.13 HOT 1
- Airstream semantics update – RFC HOT 12
- Remove `ConcurrentFutureStrategy`, `OverwriteFutureStrategy`, and `ConcurrentFutureStream` – RFC
- flatMap internal observer unsubscription bug HOT 4
- Add method variant of EvenStream.merge? HOT 5
- Update and get HOT 5
- add flatmap to ReactiveEventProp HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from airstream.