The trouble is there are at the very least three types of exceptions in Java which are intended for very different purposes.
RuntimeException class is intended for:
- programmer error, almost always unrecoverable
Error class is intended for:
- serious system or environmental error, almost always unrecoverable
Exception class (the only checked one) is intended for:
- less likely conditions that will happen during the normal course of program operation
One of these clearly stick out like a sore thumb here.
It’s unfortunate in my opinion that RuntimeException is a subclass of Exception. RuntimeException was probably misnamed and might better have been a subclass of Error and called ProgrammerError, but I digress.
RuntimeException should never happen in a reasonable situation and should almost always crash your application, like for example IllegalArgumentException or ArrayIndexOutOfBoundsException. It’s really up to the developer of an application to decide when where and how to handle Exception (the checked one) but if an API throws it then it really should be handled and definitely shouldn’t be lumped in with RuntimeException.
A top level handler for checked exceptions may or may not make sense depending on the application, but it almost certainly doesn’t make sense for RuntimeExceptions like IllegalArgumentException or ArrayIndexOutOfBoundsException, programs that encounter those programmer errors are unlikely to continue functioning in any reasonable fashion.
Kotlin does not have a goal of “data safety”, it has a goal of safer programming practice; prevent developers from making programming mistakes which the compiler can easily catch.