`Result` is now prohibited for use as a return type by compi kotlinlang #announcements

types all through my codebase. What I want is some way to indicate to the caller that a function might throw in such a way that the compiler or inspections actually speak up.

poohbar

09/13/2018, 1:19 PM

hah so there is literally a special case that will make it a compiler error or am i misunderstanding this?

kevinherron

09/13/2018, 1:58 PM

@poohbar https://github.com/JetBrains/kotlin/commit/7b70c1a2d9589b953c4e7bba1f1050742f7dd554

womp womp

elizarov

09/13/2018, 2:06 PM

Standby for updates to the KEEP. I’ll explain rationale in detail there

Short version: we have ideas on how we might integrate Result into the language in the future and we don’t have time to implement it for 1.3. But we don’t want to break your code in the future, so we are now disallowing language constructs that might acquire new semantics in the future.

👍 1

kevinherron

09/13/2018, 2:28 PM

@elizarov anything coming in 1.3 that can address concerns about unchecked exceptions?

without a Result type and following best practice to use suspend functions instead of returning Deferred/CompletableFuture, there’s no choice left to handle error conditions other than using exceptions, especially when your suspending functions do I/O

elizarov

09/13/2018, 2:56 PM

Not in 1.3, unfortunately. But we have idea on how Result, in the future, might be a path to better checked exceptions (spoiler: it is heavily inspired by Rust)

For now use have the following choices for error handling: nullable types, sealed data classes, exceptions.

For IO failures, in particular, using exceptions seems to be the best fit for most applications (now)

kevinherron

09/13/2018, 3:28 PM

if the

@throws

annotation wasn’t just cosmetic that would help (that’s still the case, right?)

looking forward to what might become of Result either way

#announcements Join Slack