Yeah, you are right! Though I think not every function coloring is necessarily bad and while Java’s implementation of checked exceptions have some edge cases, I think the idea itself is sound and it’s better to have it supported at a language level instead of recreating it with some meta-language in terms of Maybe/Result types, that loose extra-linguistic information like stack traces (yeah I’m sure they can be included, but that should be the default working).

You can have exceptions like in Erlang, OCaml, C#, Kotlin which all keep the stacktrace without having checked exceptions.

If you take a look to the history of Java, checked exceptions was there since the beginning but were weaken several times, first by the introduction of generics+inference (a type parameter can not represent an union of exceptions) then by the introduction of lambdas, the type of a lambda (the function interfaces in Java lingo) used by the standard lib, do not declare checked exceptions.

It's so bad that IOException, the king of checked exception, has two unchecked dual defined by default, UncheckedIOException and IOError that are raised randomly by the new APIs like java.nio.file.Files that do not want to deal with the complexity of checked exceptions.

Java has a checked exception problem but it does not want to recognize it.

BTW, there is another coloring in Java which is primitive vs object, but at least this one is recognized as an issue (see OpenJDK project Valhalla).