<@U1AFFRV1Q> commented on <@U3T6LDWTD>’s file <htt...

# language-proposals

[user]

@kingsley commented on @benleggiero’s file https://kotlinlang.slack.com/files/T09229ZC6/F04AVNRBLNP: IMO, making code that throws an exception fail compile time checking might be a little too strict, and we might end up entirely defeating Kotlin's no-checked exceptions. I'd rather go with your Alternative 1 (re-using existing @throw and @Throws). And exposing an opt-in flag that when enabled, shows a compile time WARNING at call sites where the @Throws have not been properly handled.
On the IDE, I'd suggest highlighting these call sites and providing quick fixes to handle accordingly

Call sites: expressions that call methods with:
checked exceptions (Java interop) or
those that are annotated with @Throws (Kotlin)

I like your use cases B, C, D and E.
B and C are features we already have today using try/catch
Regarding D and E. Again, this could be a form of opt in feature, such that current code still continues to work, and once "the flag" is enabled, current code throws "Warnings" until appropriate fixes (any of B, C, D or E) are applied.


Thinking about this, it might make sense to add a parameter (e.g `lenient`: Boolean) to @Throws to imply whether or not there should be a warning at the call site.
You could see it as a regular case of checked/unchecked exceptions, but with a more flexible design. Checked ones only show a warning/highlight (instead of a strict compile time failure)

Ben_s_Proposal_for_exception_handling_in_the_Kotlin_language