A modern programming language that makes developers happier.

kotlinlang

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?

Documentation, and if an error is likely, use some sort of result type.

Only having unchecked exceptions exactly *is* the Kotlin way.
Here some reasoning: <https://kotlinlang.org/docs/reference/exceptions.html#checked-exceptions>

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

If you could define how a checked exception would increase safety in code, maybe someone could answer.
Maybe with a concrete use-case.

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>

&gt;  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

&gt; “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`?

I think it was meant more abstractly than a specific class

&gt; “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

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.