https://kotlinlang.org logo
#announcements
Title
# announcements
j

joelpedraza

07/12/2017, 6:48 PM
I understand the reasoning for not including checked exceptions in the lang, but when it comes to java interop I need to deal with environmental errors somehow. So far I'm using my own biased Either, whose semantics I prefer over try/catch. That said, it's entirely dependent on my disciple to check if any java function I call throws some checked exception. Have any best practices emerged? Is there any linting or equivalent that can alert me to uncaught checked exceptions?
v

voddan

07/12/2017, 6:54 PM
Ideally you must always keep in mind all exceptions that your code can throw, checked or not. So nothing really changed here except that propagating the exception is always the default in kotlin
j

janvladimirmostert

07/12/2017, 6:56 PM
this actually forces you to have a catch all somewhere whereas with Java, you were under the impression that you were catching exceptions when runtime exceptions just slipped through the cracks
There’s an annotation you can use though which I believe will force Java to handle exceptions:
Copy code
@Throws(IOException::class)
c

cedric

07/13/2017, 2:29 PM
@voddan The removal of checked exceptions transfers the burden from the compiler to the programmer, which is a clear loss in safety
v

voddan

07/13/2017, 4:14 PM
My point is that the burden has always been on the programmer alone. The removing of checked exceptions is less about safety, and more about comfort.
c

cedric

07/13/2017, 4:25 PM
It's about safety too since the compiler is no longer keeping the developer accountable
This is why we like static types or exhaustive
when
clauses. For code correctness, trust the compiler over humans. Always.
The removal of checked exceptions weakens correctness.
v

voddan

07/13/2017, 6:36 PM
In your example with static types the compiler always knows the correct resolution - the types much or they don't. With exceptions, the resolution of a problem is always up to the developer. The developer must tell the compiler what to do with an exception - log it, ignore it, rethrow it, etc. Basically, you could substitute checked exception with a pop up agreement "Are you sure you know what to do with this and that exception", which the developer must sign "yes I do" in order for the code to compile.
If I designed a language from scratch, I would keep unchecked exceptions and provide an automated tool to tell the developer what exceptions may a particular method throw.
We can move the discussion to #random if you want
2 Views