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]
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)
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.
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.
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.
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 th-cam.com/video/AmUCZRRc-OE/w-d-xo.html, он правда в IOS показывает но в переводе в андроиде можно sealed классами
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
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.
Great talk!
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.
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.
Great talk
35:57 At least it has less boilerplate code than in Golang.
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.
Pooh! I'm a Kotlin newbie.... and I was under the misapprehension that it had monadic comprehension.... I'm all sad now!
Как пример здесь есть хороший доклад с использованием sealed class exceptions with hierarchies for bounded contexts th-cam.com/video/AmUCZRRc-OE/w-d-xo.html, он правда в IOS показывает но в переводе в андроиде можно sealed классами