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 reminds me of stories about directors intentionally putting ridiculously over-the-top violent or sexual scenes in their already quite violent or sexual movies for the rating board to focus on, and getting a PG-13 rating (instead of an R or NC-17) by removing it.
That's the point, Sandy doesn't tell Peter her sum, nor vice versa. Sandy only knows the sum, Peter only knows the product, and they both know that the other doesn't (yet) know the answer. It allows them (in turns) to eliminate all the pairs that produce unique sums/products, until Peter ends up with one single pair.
You can have multiple public classes in a file in Java. You just have to wrap them in an outer class, that acts like a module, and declare them “public static”. You can then “import static” the module class in other files, and you can use all these classes simply by name (without having to write OuterC.InnerClass everywhere).
- introduce a non-zero number type, define division as Number/NonZeroNumber -> Number, and provide a simple, non-verbose way to convert a Number into NonZeroNumber (with default value in case of zero, and/or direct assignment after a non-zero-check)
- optionally introduce an unsafe division operator that takes two Numbers and returns Option[Number]
Since the syntax didn't (and cannot) become any less flexible, it's unfortunately still true and always will be. As annoying as it is to struggle with the rigid syntax of Java while writing it (which also results in overly verbose code), reading it is far easier than Scala (or even Kotlin in some cases), because Java code always looks like Java code.
And since we spend way more time looking at and interpreting other people's code than writing our own, personally I think Java is better for large projects. I wish it wasn't the case but it is.
Except… when we try to build it with Jenkins on a Kubernetes cluster, this happens: https://github.com/oracle/graal/issues/7182