I agree that using a custom Result with a sealed hierarchy of errors is the way to go. However, I think you should have included the extension functions that really make this class useful. Things like ifSuccess, ifError, getOr, getOrNull, recover, map, and, andAlso, orElse, etc. Michael Bull’s Result class, Arrow’s Either, and Rust’s Result have many more examples for functions that make “railway oriented programming” possible with function chaining.

Thank you thank you thank you! I saw a very similar video yesterday from Stevdza-San and I pointed out the same concerns you had about localisation and separation of concerns. I was about to write my first Medium article on this but then your video came out with more or less the same solution. Awesome video Philip!

Absolutely! The advantage of using a sealed interface instead of strings is huge.👍

I had good luck two days ago and I was looking for a solution to this problem and a way to deal with different types of errors, but the matter was terrible, and it happened that today you are posting a video on this topic and delving into it in depth. Thank you.

Very nice Improvement, Oh boy, much to learn, much to re-factor!

The idiomatic Kotlin implementation of the classic Result pattern - a wonderful thing to know! Oh, and also - awesome usage of "when subject capture" at 12:10 - I didn't know we could do "when val"!!

Thanks for philipp, i've learn a useful and efficient way to write error class, and do error handling. It would be easier to write out logic codes ✌😁

Furthermore you could map the status code of network request to your enums so that you avoid doing too many "when" . ... Great video btw

If you have a use case class that throws its own domain level errors that also communicates with a repository, how would you encapsulate both DataError as well as the usecase's errors? I can see these types of scenarios happening where the usecase returns errors of type Error supertype only. It would be preferable to know the exact subset of errors it could be without looking at the usecase code. Any ideas?

I do this by writing custom Either sealed class left being error and right being the data we don't need the entire arrow library just few of those extensions like fold makes it lot easier. As always good tutorial 👏

Great video, thank you a lot!

Nice explanation, Thank you

very logical, great explanation

Good content I'm looking for!

Philipp has so good and solid approaches that I implement them also in iOS.

Mapping 4xx or 5xx errors from retrofit's (or ktor's) exceptions to your own enums may seem redundant to some, but this is the only way to isolate your presentation layer from the actual networking library used by the data layer. Which in turn makes it easy to switch networking libraries if the need arises, e.g. you start using Kotlin Multiplatform (which retrofit does not support). Great video, as usual!

Great video, as usual.

what about the "class Loading(data: T? = null): Ressource(data)" you had in your Ressource class before ? Would you still have a similar mechanism in the Result interface or do you manage it in an another way ?

it's better to use Arrow's Either which is pretty much the same thing but additionally provides plenty of utility functions

thank you bro

How do you recommend dealing with "Loading" state? It seems closely related. Solutions often include all-in-one (Success|Error|Loading) or creating a second class that is used in the Presentation layer that includes Loading.

I would say this is simpified version, in practices, there are more than this, and usually we will have common error handling to handle cases such as unauthorised token, internal server error, generic error message, and we would not want to handle this in every api call and this things require strategy to reduce boilerplate.

Interesting approach which looks clean, but is there actually a need to introduce another domain layer for errors? You can just use regular kotlin Result class (which also can return non-nullable data), and throw a different instances of custom Throwable classes for different error cases (or even introduce a custom base sealed interface for domain layer throwables), then just catch throwable in a ViewModel and map a different throwables to the resource strings and show different messages? And in my opinion when some domain logic functions throw exceptions makes code more readable and does not need some custom mapping when using it with mapping/flat-mapping with coroutines or rx.

Why don't we inject context using hilt?

Isn't this just what exceptions are for? Executing use cases in a runCatching block is more concise and standard than all this boilerplate. I understand that some might dislike working with exceptions, but you should at least suggest the possibility.

While I like the approach in general, I couldnt figure out yet how to use this on server side. Like when I have a ktor backend and I use such an error handling, I want to send the result back to the client via rest or websockets so my client can show the result or the error. Since we have a sealed data structure with generics trying to serialize them with kotlinx-serialization-json turned out to be a nightmare. Type erasure kicks in hard here. You can package a lego star wars set in the backend and unwrap a lego harry potter set in the frontend - not sure if lightsabers stand a chance vs magicians!

I prefer Google's AndroidNow approach using UIStates.

Great way to handling errors, But how can we use it for multimodule architectures? could you please help to me?

Hi, Philipp can you make a projet where you use koin and ktor please

Awesome😊

Great video! How about mapping data error into custom domain exceptions? I used to inject context into repositoryImpl, them throwing custom exceptions with the right string. If the erro message comes from backend, I just throw the custom exception with that message.

I see wrapped errors a lot and it makes processing the successful path require a flatMap. I prefer to throw errors and have the root coroutine catch and handle the error. This leads to much cleaner data, domain layers since they do not need to handle errors and only the coroutine in the ViewModel is concerned with errors.

What you really need is only the data and catching exceptions on the presentation layer. For general errors just use an error handler which translates the error into an action or a message. That's it.

Just use the Arrow library, instead of reinventing the wheel. You can even just copy the Either class from their git repo if you don't want the whole library :)

I've not watched the full video yet, but it looks like this approach is very similar to how errors are handled in swift

But UiText is not Serializable, how do we save state?

instead of passing message: String from your old sample you could just pass in enum class there :D and its gonna be the same but less boilerplate

Yes I like it !

How to deal with the case I want to show different pieces of UI depending on what error occurred, not just show a message, I want to show a floating smiley face when there is a network error and a blinking button when there is a password error

This seems overly complicated when you can just throw custom errors (NotFoundException, TimeoutException) and also use the *built in* coroutine function runCatching

How to handle the scenario when we need to show the message in response as error message and not the string from resources?

I'd recommend that the Succes result not take an E type (it doesn't care about the error) and have it use Nothing as it's error type for implementing the interface. Same thing goes for the D type on the Error implementation.

Instead of naming the data class error of result interface, we could name it Failure like scala did and don't have collision with error sealed interface

Is there a book or a tutorial you would recommend for learning kotlin multiplatform ?

How can you handle a network request that returns its own custom error message. Say in your example, the provided password is wrong and the error message communicates that.

As an alternative to UiText, is it a bad practice to inject the application context in the ViewModel and then use that to get string resources?

Help me understand this. I see we’re mapping the server error code to defined error type without considering the actual error message returned from the server. What if we want to show the actual error message returned from the server?

OOP is killing me 💀

What will happen when sealed interface Error and PasswordError are in different modules ?

Any particular reason for using data class for UiText.DynamicString and class for UiText.StringResource?

You and stevdza competing lmao? Same day same video lol

at 07:19 it is still confusing to me why the "typealias RootError = Error" is helpful. Can you explain this a bit more?

Thanks for the video Philipp! I have a question that has been bothering me for a long time. Why are you talking so fast? In this way, it is difficult to understand the essence of your video. I have come across this many times. (Or am I just slow? :-O)

1st one to comment