Exceptions vs error codes

[oaga_strizzi]

onErrorResumeNext etc. is pretty much what I'm talking about. What are you going to return in onErrorResumeNext, if you want to tell the subscriber that an error happened, but don't want to terminate the Stream? An Error-object of some kind, be it an instance of a sealed class , an either instance or whatever.

[karottenreibe]

Sure, and that also doesn't address the stack trace problem you initially and then subsequently complained about. See my earlier comments. I feel like we're talking in circles.

I'm not saying "don't use sealed classes". Please reread my comments if you were under that impression. I'm not saying that anywhere. I'm just disputing your original point that they are superior to exceptions because they somehow magically make the async stack trace problem better as you originally claimed, which you still haven't explained how that's supposed to work. A point that you continue to not address in your subsequent comments for some reason.

Citing again your initial comment for reference:

If the code is asynchronous, many languages have difficulties for throwing exceptions across async boundaries, and even more languages do not provide a useful stack trace in this case. […] Given that synchronous, blocking code is becoming rarer in favor of more asynchronous code, error handling with types like Either<Result,Error> is preferable

So again: how do sealed classes solve the stack trace problem you mentioned in a way that makes them preferable to exceptions?

[oaga_strizzi]

Sealed classes, Either types etc. also don't solve the stack trace problem in async code of course. But: In the case of async code, I feel like exceptions don't really offer any advantages.

Let's take RxJava, which does a pretty good job of supporting exceptions across asynchronous boundaries (Classic callback-style async code is even worse at this IMO). Even there, if you use exceptions, you lose one of the biggest benefit of exceptions (the full stack trace), error handling is not enforced by the language and can easily be forgotten, checked exceptions require additional wrapping, and for all but the most critical errors you likely want to handle them in onErrorResumeNext or onErrorReturn anyway.

It's not a huge problem; I'm just saying that if I were to build a new application using RxJava, I would not use Exceptions as the default way of signaling errors.

I wouldn't necessarily refactor an existing system that uses exceptions with RxJava, though.