Try-Catch vs. runCatching()

[@Drakind]

For me the greatest flaw with runCatching is its compatible/incompatibility with coroutines. As mentioned in the video it catches everything, including coroutines Cancellation Exceptions. Which can easily cause unforeseen behavior. There are ways to handle it, but I find it easier to have correct flow when using try catch instead of runCatching.

[@typealias]

Yeah, that makes sense - better to carefully catch the exact right exceptions in that case. It'd be cool if we could do something like `runCatching { ... }` - but type parameters aren't allowed in a catch clause, so I can't think of any way to make that happen. 🙂

[@into_the_earth]

U can do runCatching and catch throwable in the implementation. Then check if the throwable is of type T. If it is of type T, simply return a result, otherwise, rethrow. Arrow-kt uses this in its catch function. They also include a non-fatal check that rethrows any fatal exceptions like out of memory or cancellation. So it’s safe to use with coroutines.

[@reosfire]

​@@typealiasactually we can write such generic function. It should be inline and should have a try catch catching every exception, but we can return result if 'exception is T' or rethrow exception otherwise

[@ArthurKhazbs]

@@reosfire Haha yes, that's the sort of thing I thought of too when dealing with exceptions

[@ArthurKhazbs]

​@@into_the_earth Would actually be cool to have a Result that would require us to handle (or at least acknowledge) the exact kind of error we may encounter before we get to retrieve a successful value. This way we could have something akin to checked exceptions in Kotlin! :D

[@kolyakalyzhny]

Hi, Dave! Thank you for the nice video. The way I like to conceptualize it is that `runCatching` is just a smaller part of a bigger intent to leverage the power of compiler and the type system. By placing `Result`, `Either`, `Option` etc in the type signature, you address the problem of referential transparency of your functions. Consider other Kotlin features like data classes and sealed hierarchies which allow you to create your own algebraic data types. As far as I am concerned, these and other nice things help you develop a more robust and maintainable system. Besides, other languages like Swift, Rust and some older ones try to incorporate a similar approach. For anyone new to this, consider giving it a try in languages like Scala, Elm, Haskell, F# where this approach works best.

[@typealias]

Hey Kolya, thanks so much! And thanks for sharing your thoughts on this one! I do love the trends of relying more on the type system and compiler for this kind of stuff. Even when not fully embracing functional programming, it's encouraging to see that some of its concepts are becoming more mainstream, especially where type safety and referential transparency are concerned. I've only poked around with Haskell a little bit, but I might have to pick it up again soon for further study!

[@thatdougsmith]

Thank you for the helpful guidelines on this, Dave! Well done! And I'm so excited to see that your book is available!

[@typealias]

Thank you so much, Doug! 🙂 Lots of fun things happening!

[@katarinazzz]

I LOVE your content, hope you'll continue making videos!

[@typealias]

Thank you so much! Yes, more videos are on the way!

[@goobar]

Nice work! Those results were pretty interesting. I'd be curious if the larger than expected usage of runCatching() was driven be backend developers who are maybe more accustomed to a more functional approach 🤔

[@typealias]

Good thought! I'm guessing backend developers who are deep into FP approaches would use an Either class from Arrow (or elsewhere), but I think there's probably also a category of backend developers who do things in a "sort of FP" way, for whom runCatching() might have a strong appeal.

[@Poisonedyouth79]

Very good overview about the possibilities to deal with exceptions in Kotlin. Personally I prefer using the Either type of Arrow for handling exceptions.

[@typealias]

Thanks so much! Yes, lots of good reasons to go with the Either type!

[@filipbeban]

Great video, thanks Dave!

[@typealias]

Thanks so much! Glad you liked it! 🙂

[@UsmonWasTaken]

I actually prefer the way Arrow team handles the exceptions using Either, could be easier to handle nested exceptions.

[@typealias]

Yes - I kind of wish I would have included a third option in the poll for third-party Either implementations, since it seems like many developers - especially those already into FP - prefer those.

[@goobar]

​@@typealiasThat would be an interesting follow-up. I know for me, the runCatching() function was a gateway towards other solutions like Either and comprehensions coming from Arrow

[@snowe..]

I had no clue that runCatching with a result type existed in the standard library. I have used other library alternatives though. TIL

[@typealias]

Ah, cool! Yes, I do wonder how much more adoption runCatching() would have if more people knew about it!

[@markusmcgee]

run runCatching etc in Kotlin is the truth

[@LakshmanaChilukuri]

In coroutines i need to have without catching anything try { //Code } finally { /*homework*/ }