Comment

Comment by cletus

I couldn't disagree more with the point about checked exceptions. Pretty much everyone else has essentially agreed that checked exceptions were a mistake. They leak implementation details and/or pollute your interface. Practically speaking, they don't force you to deal with exceptions. They force you to catch them. Anyone who has done Java in the real world has encountered:

    try {
      // do stuff
    } catch (SomeException e) {
      // do nothing, maybe log it
    }
I strongly agree the verbosity is a non-issue. Any modern IDE just fills this in for you. Yes more verbose syntax for getters/setters would be nice but it's not a big deal.

But there's one point I wanted to highlight. Every language that comes after Java should've learned Java's lessons and some didn't.

C# quite famously did. C# really is Java 2.0. No checked exceptions, reified generics (rather than type erasure) and some cool stuff too (eg LINQ, partial classes).

Other languages (eg Go, Rust) largely moved away from exceptions entirely. Personally I agree with this. Exceptions are a false economy that devolve into control flow that's hard to follow (eg Java has a parse number from string that throws a ParseException if the parsing fails and that's just not an exception).

But the big one is dependencies. Every external dependency system that came after Mavaen should be at least as good and many aren't. I'm looking at you, Go. This was a shocking omission for something aimed at being a better systems programming language (which it never would be as a GC language but that's another story).

But Java is proven, mature and sufficient. That's why it's still used.

parent cletus 4 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton