KotlinConf 2019: Error Handling Strategies for Kotlin Programs by Nat Pryce & Duncan McGregor
Вставка
- Опубліковано 19 гру 2024
- Recording brought to you by American Express. americanexpres...
Kotlin largely inherits Java's exception mechanism, but exceptions and functional programming are uneasy bedfellows, leading to most projects adopting a wing-and-a-prayer as their error handling strategy.
I needn't be so ad-hoc though. In this session we compare and contrast different techniques for handling errors in Kotlin programs. We will discuss the sweet spots, pitfalls and trade-offs encountered in each technique, illustrated with examples from real projects.
Resources:
KotlinConf website: jb.gg/fyaze5
KotlinConf on Twitter: / kotlinconf
Kotlin website: jb.gg/pxrsn6
Kotlin blog: jb.gg/7uc7ow
Kotlin on Twitter: / kotlin
#KotlinConf19 #Kotlin #JetBrains
About the Presenters:
Nat has been programming for coughty-cough years, and programming in Kotlin since it was in beta. He introduced Kotlin into his current client and his team used it to deliver business-critical, customer-facing web applications. Now many teams in the company are happy users of Kotlin, and it powers many of their core services.
Duncan has been programming professionally for 25 years. He was lucky enough to ride the Object-Oriented wave of the 90s, the Agile wave of the 00s, and what he is convinced will be called the Distributed-Functional wave of the, erm 10s.
What is failure [0:57]
Java [3:52]
But history happened [6:17]
Kotlin [7:43]
Best way - it depends [8:28]
Fuzz test to ensure no unexpected exceptions [13:51]
Exceptions are fine when ... [14:51]
Avoid errors [17:44]
Total Functions [18:40]
use null to represent errors [20:52]
A common convention in the standard library [22:41]
String.toIntOrNull()
Errors handled with elvis operator [23:16]
But the same construct represents absence and error [24:05]
Convert exceptions to null close to their source [25:00]
Using null for errors cases in fine when ... [25:33]
Move errors to the outer layers [26:29]
Use a algebraic data type (sealed class) [28:45]
A example Result type [29:06]
(example from Result4k)
forced to consider the failure case [30:00]
Convenience operations instead of when expressions [30:48]
No language support for monads [33:45]
Arrow's binding API [34:32]
Flatten nesting with inline functions & early returns [35:06]
How to model error reasons in the Failure case? [36:33]
A Result type is fine when ... [39:36]
Design your system to be robust to errors [40:43]
The sweet spot for our system [42:30]
Highly underrated talk, this should get some more visibility!
37:00 - Incorrect statement that exceptions are slow on `throw` but not on its creation.
Contrary, they are slow on `instantiation`. (StackTrace is being filled at this time)
Result is not a monad. It doesn’t contain any Monadic operations like flatmap
I don’t get why they say at around 29:00 that the standard library’s Result class should be ignored. That’s just so easy to use and yet everyone is trying this sealed class approach. Could anyone explain?
The standard library version can only wrap an exception, not any old class. It is really designed for returning an exception that has already been thrown, not avoiding throwing them in the first place.
At 35:09 it looks like the compiler has been fooled using "Nothing" but I am failing to understand what exactly happens during runtime when json load fails (the first statement in the function) it definitely does not throw because you have returned "it". I am a bit confused here
The "return" you are seeing returns from from the handlePost function, not from onFailure. The onFailure method never returns, because the outer function returns first.
How to rate this talk? It depends :D
I love how they see that there are no universal truths in programming, only context-valid ones.
35:57 At least it has less boilerplate code than in Golang.
Great talk!
Great talk
Pooh! I'm a Kotlin newbie.... and I was under the misapprehension that it had monadic comprehension.... I'm all sad now!
I found it a bit confusing the way they used the term `partial functions`. It has a specific meaning in FP, and they overloaded it... causing some confusion.
they use it by its mathematical definition if I'm not mistaken
I believe you are confusing partial functions with partially applied functions.
Partial functions are those which cannot return a result for some inputs, so have to signal an error if such an input is supplied. If we can make more functions total, we have fewer such errors to deal with.
Как пример здесь есть хороший доклад с использованием sealed class exceptions with hierarchies for bounded contexts ua-cam.com/video/AmUCZRRc-OE/v-deo.html, он правда в IOS показывает но в переводе в андроиде можно sealed классами