In future, could Kotlin have checked exception?

Language Design
#101

First, I love the fact that checked exceptions are missing.
I do use the functional way, though: the Try-class.

The Try-class with getValueUnsafe is the same as unchecked exceptions.
If you don’t have that function, you do need to check the type -> checked exception.

Try-classes with all their callbacks are harder to chain.
But I believe something like that can be solved the same way suspend already solves multithreading.

try fun foo() : String = ""
fun outside() = when(val v = foo()){
    is Success -> println(v.value)
    is Failure -> println(v.failure.message)
}

try fun inside(){
     val value = try { foo() } catch(e : Exception) { it.message }
     println(value)
}

or if you want to simple rethrow on exception:

try fun inside() = println(foo())

Here you tell people clearly that you expect some exception to be thrown.
The drawback:

  • Silencing can easily be done by adding tthe getValue or adding try before the function.
    This way, either lots of functions would become try-functions, or a lot of functions are silenced.
  • Also, it doesn’t tell which exceptions can be thrown.

If a (way better) function like this would be implemented, it would be done in arrow-kt, combined with arrow-meta.

#102

Yes, your idea using “try” functions could/will solve the compatibility to Java, something like I mentioned here.

#103

Maybe ask in the arrow-group on slack if they have ideas how you can implement it using arrow-meta?

#104

Still missing checked eceptions, none of this solutions worked out for me i always have to write boilerplate code see to my last posts why… i still think giving developers the option to use them is always good

1 Like
#105

Is there a Kotlin fork having checked exceptions already?

1 Like
#106

Just had a thought a compromise between Java’s pedantic enforcement of checked exceptions and the wild west of no enforcement would have been to treat it like lint warnings:

  • have the distinction between exceptions that are unexpected and those that are expected, In Java terms Exception vs. RuntimeException
  • If a function throws or calls a piece of code that is declared to throw a “checked” exception there should be a lint check to see if the function either catches the exception or declares that the function throws that exception
  • like normal lint style checks provide a way to suppress for the line, function, class, or file
  • provide a way to specify if that lint check globally is ignored, produces a warning, or produces an error

That would let the programmer be as pedantic as they want to be.

2 Likes