RxSwift: Revisit typed errors?

It looks like Swift 5 introduces Result<Value, Error: Swift.Error>.

This thing compiles:

struct Observable<Value, Completed, Error> { }

but it would be ideal if

struct Observable<Value, Completed = Never, Error = Never> { }

would also compile.

As I see it we could introduce something like

struct ObservableXXX<Value, Completed, Error> { }

and make

typealias Observable<Value> = ObservableXXX<Value, (), Error>

I think that if we did that it would be win/win situation because we would maintain backwards compatibility and provide more type safety options.

Once Swift adds default generic arguments, we could just make:

struct Observable<Value, Error = Never, Completed = Never> { }

1rst stage: First provide additional features and type safety together with more dynamic API. 2nd stage: Make a breaking change by effectively changing from:

struct Observable<Value, Completed = (), Error = Error> { }

to

typealias DynamicObservable<Value> = Observable<Value, Completed, Error>
struct Observable<Value, Completed = Never, Error = Never> { }

I think we could implement first stage for RxSwift 5.0. When should we make the second stage is hard to tell because there is a lot of legacy and educational code out there. It would be ideal if Swift 5.0 introduced default generic arguments and if we just made it all at once, but it seems like this is not the case.

For the second stage one could make a global rename of Observable -> DynamicObservable, so it’s not a horrible breaking change.

Anyway, these are my thoughts.

Hi, guys!

I personally agains typed errors! 😃

• they do not provide any value (in my opinion)
• introduce unnecessary mess (flatMapError, mapError, attemptMap , NoError and family)
• swift does not support typed throws , and even if it would I would not like RxSwift to have typed errors (look at RxJava)
• it gonna break cross language similarity

Also I feel like it violates duality math behind Rx

@hfossli that’s a great point in general but I also feel like it’s a “developer concern” and not necessarily a RxSwift concern. The “official” ReactiveX standard is failing on sequence error.

I wouldn’t be opposed to a type of Observable that can’t fail / provides typed errors but I’m not sure it’s exactly in the scope of this library …

Also, some people rely on ReactiveX-based implementations to work the same across platforms so having this “discrete” implementation that is only relevant to RxSwift could be highly confusing and needs to be well thought out IMO.

In 99% of the cases these issues are resolved with using a Result type, which is just a “standard” part of RAC, really. RxSwift gives you the freedom of choosing how you want to model your results and doesn’t “bind” (pun not intended) you into a specific format (for better or worse)

Just me $0.02

I skimmed over this issue quickly as it’s a topic I would like to track and provide feedback. @kzaher is there a reason you want not permit custom types for Complete? We don’t support it now but I think it would make sense to extend this possibility for the future. Especially because we don’t need NeverCompletes as it won’t have any compiler support compared to Never.

If this was the new Event enum in RxSwift.

public enum Event<Element, Completion = Void, Failure: Error = Error> {
  case next(Element)
  case failure(Failure)
  case completion(Completion)
}

It can have strong compile time guarantees for switch exhaustiveness:

// enum is exhaustive
switch Event<Int, Never, Never>.value(42) {
case .next(let element):
  print(element)
}

// does not complete but can error out or emit an element
switch Event<Int, Never, Error>.value(42) {
case .next(let element):
  print(element)
case .failure(let error):
  print(error)
}

// empty behavior
switch Event<Never, Void, Never>.completion(()) {
case .completion(_):
  print("completed")
}

// throw behavior
switch Event<Never, Never, Error>.failure(NSError()) {
case .failure(let error):
  print(error)
}

// never behavior
switch Event<Never, Never, Never>.value(fatalError()) {
}

If possible I would also follow the precedence of Swift for the naming scheme (you could also argue that we should follow the precedence of Rx, I know).

Here is the rationale for the naming Result ended up with:

While several members of the community supported naming the cases value and error, overall While several members of the community supported naming the cases value and error , overall people seemed to prefer the original proposal’s case names: success and failure . After considering this feedback, the Core Team has come to agree that these are excellent “semantic” names which work better than value and error as labels for the current state of a Result value. They read more fluently when constructing a Result or pattern-matching on it, especially when the value type is () , and they avoid confusion over the fact that a Result is itself a value.

The concern that originally led the Core Team to suggest renaming the cases was about the cognitive load of using different names for the cases, case accessors, and type parameters of the same type. It’s easy to remember these differences when reading the proposal, but this will predictably become an annoyance after a few months. But this doesn’t specifically require using value and error ; any consistent set of names will do. So we should consider whether we could use success and failure for the type parameters and case accessors.

Success and Failure are reasonable choices for the type parameter names. Failure is particularly nice because it’s a problem to have both an Error parameter and a global Swift.Error type: not because the shadowing is difficult for the compiler, but because the reuse of the name makes code harder to read and — perhaps more importantly — makes it unnecessarily awkward to talk about in person. These names are also rarely used in code, as they only ever need to be written within extensions of Result .

Case accessors are a more complex question. The current proposal doesn’t include case accessors, but the original proposal did, and we’re anticipating a future proposal that will add automatic synthesis for case accessors. That synthesis will undoubtedly use names based on the actual case names, so at a first glance, it seems imprudent to use case names that we’re not sure we’d want for the accessors. However, feedback on this review has led the Core Team to more seriously consider this issue, and it now seems quite complicated. A name that’s a good name for a particular state of an enum (like failure ) might not be a good name for a value carried in that case (like error ). It may be true that case accessor names will always end up feeling a little contrived, and so it’s just better to use the actual case names because they’re easy to interpret. More importantly, we don’t want to burden this proposal because we haven’t resolved those questions yet to our satisfaction.

Accordingly, the case names are revised (back) to success and failure , and the type parameter names are revised to Success and Failure .

Source

I’m playing with ideas for RxSwift 5.0 here. Didn’t have much time to play with this, but hoping to get benchmarks running soon so we can estimate performance impact.

I’m trying to simplify the project structure while doing this, but there is bunch of code in the project 😃

I’m publishing this just in case anyone is interested in the prototype and has early feedback.

Once benchmarks are running, we’ll estimate the performance impact, optimize for the benchmarks and then port the rest of the project once we’ve profiled it.

At least that’s the plan.

Hi guys,

It has been a long time since I’ve responded here. Releasing 4.4.1 was a priority. I’m hoping that 4.4.1 is the last patch we need to release for 4.x version and that the next version will be directly 5.0. I guess this is the only major change for 5.x.

The plan for 5.x would be to first create a 5.x branch and create a prototype of generic Observable<Value> = ObservableSource<Value, (), Swift.Error>.

I’ll try to do that this or next week, but can’t make any promises. After that I guess it’s a matter of porting all of the operators.

protocol CompletableToken {}

struct Completes: CompletableToken {}
struct NeverCompletes: CompletableToken {
	private init() {}
}

struct Observable<E, C: CompletableToken, F: Error> { /*...*/ }

@nikita-leonov I don’t think this limits it to just NeverCompletes or Completes.

@kzaher nice. I didn’t expect Completed in the list for parametrization.

If we are doing this, then we are doing this right. Completed event is no less important than any other. Complete communicates does the state machine have completed state. Is the state machine finite.

I actually mostly use

Single<Value, Never>
Observable<Value, Never, Never> (wrapped in `Driver`)

All other combinations are rare IMHO.

Does it mean Completable can be expressed as Observable<Never, Void, Error>?

I guess you can do Observable<Never, Void, Error> or Observable<Never, Void, Never> depending on your use case. Define it as you wish.

Is there a plan to rethink all the traits in such way?

Yes, we would generalize all of them, not just Observable.

As an alternative it is still possible to stick to Observable<Value, Error> and implement not completable as one more trait.

I don’t think ignoring Completed makes sense. You will need to typealias Observables anyway if you want to make your code sane. The most compelling purpose of introducing Error parameter is to be able to communicate that the state machine can never enter final error state. Final complete state is almost as bad if you want to play the type safety card. Read my posts above for rationale.

Anyway I think I understand a current state of things now. I think it is ok to have two FRP frameworks, one more strict (ReactiveSwift) another one is less strict (RxSwift) …

I don’t think this sentence characterizes the spirit of this project correctly and there isn’t a parallel between errors from RxSwift and ReactiveSwift.

Both RxSwift and ReactiveSwift have something named error in their events, but they aren’t conceptually interchangeable.

You would use error in RxSwift as a short switch:

• Something unexpected happened
• I don’t know how to handle this, just send it to server and log it, I have no idea how this is happening (and yes, delete the logs because of GDPR after you’ve figured out what the hell is happening)
• But I also don’t want to kill the entire app because of it.

It is not recommended to encode any business logic in errors, catch them and then parse the error information. This is anti-pattern IMHO.

I’m usually using resultish values as sequence elements because you want the compiler to notify you if you’ve forgotten to handle some case.

There are some type safe properties that this project offers that some other projects don’t:

• compile time guarantee that the sequence generates single, 0-1 or none elements (Single, Maybe, Completable)
• compile time guarantee that you won’t have deadlocks and that you can safely reason about multi-operator compositions without worrying about data races, sharing strategy guarantees (Driver, Signal and other traits from RxCocoa)
• there are also guarantees that certain sequences won’t error out (Driver, Signal and other traits from RxCocoa), but yes, there are no general guarantees regarding erroring out.

ReactiveSwift could also advocate that their Signal, Properties, etc… are the latest and coolest things ever.

… and let users choose what they want. Cheers. 😃

Sure 😆 🥂 🥂 🥂

There is just one tiny detail nobody is mentioning, so I’m going to mention it anyway. Maybe somebody will find this information useful.

There are actually 3 events in Observable (or 4 in RXS/SignalProducer) and for some reason everybody is forgetting about Completable event (or Completable/Interrupted in RXS case).

I can’t be entirely sure why people are advocating for parameterized errors, but I’m assuming that they are probably advocating this because they want to be sure that they’ve handled all of their errors, and their user interface won’t die because they’ve forgot to handle an error (that’s one of the reasons why we have Driver/Signal in RxCocoa).

BUT

Even if we parameterized Error type, that still wouldn’t be enough to guarantee that your user interface won’t die. Your sequence can Complete and you also need a guard against that.

This is not just theoretical concern, consider this code:

let iCanSometimesErrorOut: Observable<Int, Error>;
let iMSafeToBindToUI: Observable<Int, NoError> = iCanSometimesErrorOut
     .catchError(x => Observable.empty())

Hint: If you’ve found this comment, more useful approach is maybe retry family of operators but be careful with them, because you could accidentally overwhelm your service and create a DDOS attack on your service if you don’t properly design a retry strategy, so try to implement some binary back-off retry strategy to prevent these kinds of issues.

This is perfectly safe to bind to user interface, but it doesn’t prove compile time that your code is correct just because it has NoError. You UI will still die even if no error is thrown. Complete event is also a silent killer.

I’m not trying to say that reminding the user that somebody hasn’t handled the error properly isn’t a nice handy thing (I find this really useful with Driver/Signal from RxCocoa), but that it doesn’t provide you with guarantees that one would assume from the code itself.

The case I’ve presented isn’t theoretical. I’ve been watching people day after day people writing code like this (usually with Driver, but nothing in the interface would prevent people from doing the same thing with Observable if we added typed errors). If you are thinking the problem was people, I’m not that convinced, these were very capable people IMHO that I respect, but they just needed time like everyone else.

One could think, ok, let’s add typed complete event.

let iCanSometimesErrorOutAndComplete: Observable<Int, Error, ()>;
let iMSafeToBindToUI: Observable<Int, NoError, NoComplete> = iCanSometimesErrorOut
     .catchError(x => Observable.never()) // <--- just change to never

This again won’t work. One can just replace empty with never and you are back to square one. Your program type checked, your sequence will never complete, but your user interface is dead again because it won’t ever receive any elements.

If errors regarding .catchError(x => Observable.empty()) are common, it is reasonable to assume that errors regarding .catchError(x => Observable.never()) would be common somewhere approx same order of magnitude.

But yes, we don’t have NoError type in Observable, sorry ¯\_(ツ)_/¯

Also in my opinion Observable based API are perfect example of Open Closed Principle, looking on API like:

func getSomething() -> Observable<Something>

The data may come from cache, network, streaming connection or both. It allows to model you app without worrying that changes of platform will break something. Adding typed error will most likely break the client if you change type of the error or add another case to your Error enum

Also if I’m allowed to bikeshed here a little, I can imagine that we could have two event types.

public enum Event<Element, Failure: Error = Error> {
  case next(Element)
  case failure(Failure)
}

public enum CompletingEvent<Element, Failure: Error = Error> {
  case event(Event<Element, Failure>)
  case completed
}

If you look closer here you realize that we just added support for Completion as Void or Never. In fact we can go even one step further, as Event is simply the same as Result. The Swift community will likely extend the type with a default for the generic type Failure to Result<Success, Failure: Error = Error>, which is the exactly what we want here as well.

I can imagine (aside from slightly different names) that RxSwift could adopt such Result type as its Event type, and provide a wrapper to restore completeness.

// new `Event`-like type which does never complete
enum Result<Success, Failure: Error = Error> {
  case success(Success)
  case failure(Failure)
}

// revamped `Event` type 
enum CompletingResult<Success, Failure: Error = Error> {
  case result(Result<Success, Failure>)
  case completed
}

What do you think?

I prefer error as well. It represents the Swift.Error type anyways. I was mainly asking about the generic letter you assigned to it (F). I imagine you did this because E is for the element type, in which case it might make more sense to do Error: Swift.Error instead of F: Swift.Error. But alas, I don’t mind that much 😃

To me it seems to have typed error https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md or maybe i am missing something.

The declaration is

public enum Result<Value, Error: Swift.Error>

Which allows to define the type, right?

This thread has some really interesting insights, but - it is 3 years old and Swift’s default generics isn’t around the corner. This could likely be a RxSwift 7 feature is Swift’s features progress accordingly. When the time comes we can revisit this thread or open a new one that links to this one.

Thanks to everyone who participated and for the great ideas!

About completion subtype, that could basically be fine, I think. But it would be something that needs to be investigated for RxSwift 6, probably.

Starting from the end - I meant “conform” in the actual meaning of the word (e.g. “shoehorn” the event type into a result even though it doesn’t represent the same thing), not the technical sense of protocol conformance.

About the rest - I respect your opinion but I personally highly disagree. I think you are misinterpreting what this project is about. It’s not about reinventing Reactive Programming. It’s about providing the ReactiveX standard in a great Swift-centric API that follows the same standard across all of its platforms, which is one of the biggest promises of Rx in general.

RxSwift’s purpose isn’t to steer away from Rx (unless we’re talking about some operators or method names, but definitely not core concepts), but to provide this Swift-centric implementation that is understandable, stable and expectable. This is different than ReactiveSwift, for example, in the sense they’re making their own API without regards to Rx specifically or any other standard (for better or worse).

What you call a “historical quirk” is basically a standard. It’s like you’ll make a browser that decides HTML is outdated and would decide to make its own markup language. It might be “nice”, but it’s not practical or a good move.

In general, I personally find the next, error, completed standard very simple and basically it just “makes sense”, to me.

This entire post is my personal opinion. I don’t represent Krunoslav’s vision or anyone else’s, but this is how I teach Rx to people (it’s a platform-agnostic standard), and the thoughts you share here are a large deviation from that IMO.

@nikita-leonov I don’t think this limits it to just NeverCompletes or Completes.

You could use a closed class hierarchy instead of a protocol.

RxSwift should use default Swift error mechanism since the library is meant for Swift language users.

Moreover in scenarios where throws is used in Rx which is very limited it can be replaced with Result

If Swift team decides to ship a built in Result type and proclaims that this is the default error handling mechanism, and if Apple is planning to migrate all of their existing APIs to conform to their new Result type, then yes, we will also migrate towards it.

I also assume that typed throwing from Apple is just a confirmation that introducing typed errors in Rx is a right way to go that will make Rx more native to Swift.

What do you mean by this? Links?

It is more an extra confirmation to justify a change, rather than an architectural need that limits an implementation.

I’m not sure what do you mean by this.

When I say parametrized typed error throwing, I mean something like this.

static func someMethod<T>() throws T {}

I was a bit out of the loop, so maybe I don’t have the latest information. Is this coming?

About opting in to typed errors, would that maybe require Swift being able to have default values for parameter type information? I don’t know if that exists, is a good idea or anything – just popped in to my mind… E.g. class Observable<Element, ErrorType = Error> so that it is possible to both write Observable<String, MyError> and Observable<String>?

Or is there other ways of opting in?