https://kotlinlang.org logo
#getting-started
Title
# getting-started
t

tenprint

11/09/2020, 4:34 PM
What is the "kotlin way" of doing this: In Java you could throw checked exceptions, which would give you compile-time feedback letting you know where in your code you need to implement try/catch. So for example if you threw an exception in a method that's used in many places, the compiler will force you to handle where ever it is called. However in kotlin, exceptions are unchecked, so you do not get any compile-time feedback. You may accidentally miss some places where you need to try/catch. What is the "kotlin way" here?
👍 1
r

Ruckus

11/09/2020, 4:38 PM
Documentation, and if an error is likely, use some sort of result type.
v

Vampire

11/09/2020, 4:39 PM
Only having unchecked exceptions exactly is the Kotlin way. Here some reasoning: https://kotlinlang.org/docs/reference/exceptions.html#checked-exceptions
t

tenprint

11/09/2020, 4:41 PM
@Vampire yes I read that link before but it just says "we don't do this", it doesn't say "do x instead" what do you do instead to ensure some safety in your code?
v

Vampire

11/09/2020, 4:42 PM
If you could define how a checked exception would increase safety in code, maybe someone could answer. Maybe with a concrete use-case.
c

Casey Brooks

11/09/2020, 4:50 PM
In JVM, you can use the
@Throws
annotation https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.jvm/-throws/. I don’t think it shows compiler warnings or anything, though In general though, Kotlin discourages this as checked exceptions generally enourage poor practices with error handling. Kotlin prefers a “happy path” coding style with a centralized error handler, rather than handling or bubbling exceptions manually at every step of the data processing pipeline. If errors are expected, you should write code in a way like “if an error happens at any point, the whole pipeline fails” and the error-handling wraps the entire pipeline. Alternatively use a “Result monad” to enforce the fact that any given operation may fail and should be checked, but still allowing for the ease of “happy-path” or “railway-oriented” programming https://github.com/kittinunf/Result
🙏 1
n

nanodeath

11/09/2020, 5:52 PM
If errors are expected, you should write code in a way like “if an error happens at any point, the whole pipeline fails”
this. and there might be logical places to catch or retry, too. admittedly this seems to lead to some
try-catch Exception
branches, but it's better that than a potentially long list of specific checked exceptions that are rethrown at multiple levels
t

tenprint

11/09/2020, 6:28 PM
“if an error happens at any point, the whole pipeline fails” and the error-handling wraps the entire pipeline
What is the Kotlin construct for "pipeline"?
Flow
?
n

nanodeath

11/09/2020, 6:33 PM
I think it was meant more abstractly than a specific class
t

tenprint

11/09/2020, 6:42 PM
“if an error happens at any point, the whole pipeline fails” and the error-handling wraps the entire pipeline
this is precisely what i loved about Rx, you only had to implement the error block in your
subscribe
method and call it a day however my org is moving away from Rx so it would seem that a pure kotlin alternative would be
Flow
, but pls let me know if there are other patterns I should check out
j

Joost Klitsie

11/09/2020, 7:33 PM
I "resolved" it using a result object. Something is either Success, Loading or Error state. You can code way more concise using that, and I usually only catch errors exactly at the point where they originate, and then pass on a result value down stream. It is a way to force yourself to always code the unhappy path as well, as wherever you are handling code you dont just have a value, you have to handle the different result types.
7 Views