Comment by marginalia_nu

Comment by marginalia_nu 3 days ago

11 replies

View on Hacker News

Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful.

It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in the last 17 releases.

agos 3 days ago

What other language made them think checked exceptions were a good idea?

Reply View 10 replies
  • bigstrat2003 3 days ago

    They are a good idea. They solve the problem that you don't know where an exception is coming from (the "invisible control flow" complaint), and let the compiler help you to avoid mistakes when refactoring. There is zero valid reason to hate on checked exceptions.

    Reply View 3 replies
    • gbear605 2 days ago

      The only problem with them is that they don’t work well with lambdas (and related features like Stream). If you need to call a method that throws a checked exception inside of a Stream, there’s no good way to pass it up other than re-throwing it as unchecked or some other hack (like collecting all the thrown exceptions in a separate loop).

      A different implementation of lambdas that allow for generic exceptions would probably solve it, but then that introduces other issues with the type system.

      My other complaint is that the standard library didn’t have enough pre-made exceptions to cover common usecases.

      Reply View 2 replies
      • samus 2 days ago

        When you use lambdas you lose control over when and how often your code gets executed. Since checked exceptions are very often thrown by code that has side effects, I'd consider the friction to be a feature.

        > collecting all the thrown exceptions in a separate loop

        It's really not comfortable to do so in Java since there is no standard `Either` type, but this is also doable with a custom collector.

        Reply View 1 reply
        • gbear605 2 days ago

          > Since checked exceptions are very often thrown by code that has side effects, I'd consider the friction to be a feature.

          This is true, but I think that it’s partly true because checked exceptions are cumbersome here. In my ideal world, the majority of functions would throw exceptions, testing cases that today are either missed or thrown as unchecked exceptions.

          Reply View 0 replies
  • ivan_gammel 3 days ago

    Some inspiration came from C++, Modula-3, CLU etc. (note, inspiration, not validation of the idea)

    They exist since v1, which had very different philosophy than Java of 2010s-2020s. 1990s were an interesting time in language design and software engineering. People started reflecting on the previous experiences of building software and trying to figure out how to build better, faster, with higher quality. At that time checked exceptions were untested idea: it felt wrong not to have them based on previous experience with exceptions in C++ codebases, but there were no serious arguments against them.

    Reply View 0 replies
  • vips7L 2 days ago

    They are a good idea. Checked errors are so important for correctness. HN’s darling Rust exclusively uses checked errors.

    Reply View 1 reply
    • ahoka 2 days ago

      Rust has panic, although intended for “unrecoverable” errors only.

      Reply View 0 replies
  • hocuspocus 3 days ago

    I assume it was the other way around, a slight twist to exceptions, only enforced by the compiler (the JVM doesn't care about checked/unchecked) probably seemed a cheap and reasonable way to implement explicit error handling. Given that Java ergonomics of the time didn't offer any convenient and performant way to return multiple values instead.

    Reply View 1 reply
    • MBCook 3 days ago

      I always thought of it as a reaction to the “your program can throw anywhere for any reason due to an exception” nature of C++.

      So they added checked exceptions. That way you can see that a function will only ever throw these two types of exceptions. Or maybe it never throws at all.

      Of course a lot of people went really overboard early on creating a ton of different kinds of exceptions making everything a mess. Other people just got into the habit of using RuntimeExceptions for everything since they’re not checked, or the classic “throws Exception“ being added to the end of every method.

      I tend to think it’s a good idea and useful. And I think a lot of people got a bad taste in their mouth early on. But if you’re going to have exceptions and you’re not going to give some better way of handling errors I think we’re probably better off than if there were no checked exceptions at all.

      Reply View 0 replies