That is an extremely debatable topic. Which is why kotlin completely ignores checked exceptions.

Frankly, Id rather have a result and optional/nullable type like in rust/kotlin than deal with exceptions in any capacity.

Kotlin’s decision to make every exception runtime is the main reason I don’t use Kotlin. It’s especially baffling that they realized the issue with implicit nullability and got rid of it (though not with Java methods, which opens another can of worms), then went and intoduced implicit “exceptionality”.

The correct way to deal with Java’s checked exceptions would have been introducing a Result type, or, preferably, type algebra, like in TypeScript, so something like:

  fun openFile(fileName: String): File | FileNotFoundException {…}

Then you could handle it similarly to null:

  val content: String | FileNotFoundException = openFile(“myfile.txt”).?read()
  …then you have to do a check before you use content as a String…

or

  val content: String = openFile(“myfile.txt”)?.read() ?: “File not found”

(There could also be other possible ways of handling the exception, like return on exception, jump to a handling block, and so on.)

In fact, null should be treated as an exceptional value the same way all exceptions should be.

This would be my preference. I like `Either`or some other container type, but a simple union that makes exceptions explicit works also.

Checked exceptions are gross, they get in the way when you're prototyping, and you end up just ignoring them anyway (since you're prototyping)

The ergonomics of checked exceptions may be debatable but compared to golangs explicit error handling at essentially each function call is definitely worse.

Yeah, I've got a lot of Java experience and a wee bit of Go language experience and I agree with you. I like Go in almost every way except for it's error handling. It's just wrong to have to check every goddam function one by one

I guess that's the reason why most Java programs I use cannot do proper user-facing error messages. Because it is so easy to just ignore error handling. The exception will be caught by the top-level, right? This is how almost every Java cli tool prints a stacktrace on even most trivial user errors like file not found.

Having to deal with errors and forcing the developer to do proper error handling is a good thing.

I don't mind Go's errors. I do mind the complete lack of hierarchy in that. Java's exceptions are hierarchical. I can create an exception that specializes from `IOException` and that I feel is really powerful. Go added this half-baked and much later. So, most FOSS libraries don't support it yet.

Both Java checked and unchecked exceptions are inferior to signaling errors by return values like Go/Rust/Haskell do.

Exceptions are not composable, cannot be generic, and it is not visible in the source code which lines can throw, so every line is a potential branching point.

I don't think the jury will ever return on this topic.