Try-Catch vs. runCatching()

Рет қаралды 3,461

Күн бұрын

I recently put out a poll asking whether Kotlin developers prefer using try-catch expressions or the runCatching() function, and the results were fascinating. In this video, I'll cover those two options, the results of the polls, and my assessment of the trade-offs involved when choosing between them.
✨ New to Kotlin? Start here: typealias.com/start/
... or pick up the new Leanpub Edition! book.typealias.com/
🚀 I just launched a new email newsletter!
Sign up here: newsletter.typealias.com/
00:00 The Exception-Handling Poll
00:22 Try-Catch Expressions
01:48 runCatching() and Result
03:00 Results of the Poll
03:18 Other Options
04:22 Trade-offs
#kotlin #androiddevelopment

Пікірлер: 25

@Drakind 5 ай бұрын

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 5 ай бұрын

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 3 ай бұрын

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 3 ай бұрын

@@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 2 ай бұрын

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

@ArthurKhazbs 2 ай бұрын

@@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 4 ай бұрын

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 4 ай бұрын

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 5 ай бұрын

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

@typealias 5 ай бұрын

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

@katarinazivkovic3102 3 ай бұрын

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

@typealias 3 ай бұрын

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

@filipbeban 5 ай бұрын

Great video, thanks Dave!

@typealias 5 ай бұрын

Thanks so much! Glad you liked it! 🙂

@snowe.. 5 ай бұрын

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

@typealias 5 ай бұрын

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

@goobar 5 ай бұрын

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 5 ай бұрын

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.

@UsmonWasTaken 5 ай бұрын

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

@typealias 5 ай бұрын

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 5 ай бұрын

@@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

@Poisonedyouth79 5 ай бұрын

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 5 ай бұрын

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