5 ms·

> which should be caught and dealt with accordingly Which is easy when you have an Either<L, R> construct for your returns or when you have checked Exceptions,

> which should be caught and dealt with accordingly Which is easy when you have an Either<L, R> construct for your returns or when you have checked Exceptions, which Java devs dislike. So you get errors like this, because devs are often not aware or misremember all the failure modes of calls they make. Because they're only humans and they're using tools and practices that like to pretend everything that matters is the happy path.

fiddlerwoaroof 6y ago
Yeah, from a static safety perspective, Java’s checked exceptions are a big missed opportunity: if Java could have figured out a better syntax for them that was less annoying to deal with they could have been really interesting. As it is, they actively prevent certain sorts of abstractions.
- MaxBarraclough 6y ago
  > they actively prevent certain sorts of abstractions. Like what?
  - fiddlerwoaroof 6y ago
    It’s been a while, but every time I’ve tried to mix higher order functions and checked exceptions in Java, I’ve found it pretty painful: there’s some annoying type checking issue around the way lambdas work in Stream.map or similar. Maybe I’ll come up with a demo when I’m back at my desk.
    - hyperpape 6y ago
      The lambda design team knew this was a pain point, and considered some designs that could've alleviated the problem (http://mail.openjdk.java.net/pipermail/lambda-dev/2010-June/001484.html http://mail.openjdk.java.net/pipermail/lambda-dev/2010-June/...). I think they decided it wouldn't work well, but it's at least possible to do things here. That said, I think the decision to do lambdas the way they did tacitly killed checked exceptions.
  - jrimbault 6y ago
    You can't have an interface implementation throw exceptions not declared in the interface, hence all implementations of a given interface have to declare the same failure modes. And then everything is nicely coupled.
    - kllrnohj 6y ago
      A great example of this is ByteArrayOutputStream's close(). It's documented to do literally nothing, and yet you still have to "handle" an IOException that will never, ever happen. https://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html#close() https://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayO...
      - hyperpape 6y ago
        The language doesn't force them to do that--they could override the interface and not declare the Exception. Then if you were working with an object declared to be ByteArrayOutputStream, you wouldn't need to handle the Exception. If working with the interface, you would, because that's the point of an interface.
        twic 6y ago
        Yes, this is a poor example. The declaration of that exception is either a mistake, or a way of reserving some wiggle room for future changes.
    - hyperpape 6y ago
      This is backwards of how I think about it, so I'm curious what you're thinking. If an implementation of an interface can throw an exception that its interface doesn't declare, that breaks the abstraction. How can you safely use the interface? You either have to catch Exception (which is effectively the same as wrapping every exception in some InterfaceException class), or give up on handling any Exceptions thrown by the interface.
      - jrimbault 6y ago
  - ThorinJacobs 6y ago
    I've run into this when working with lambdas in particular. Say for instance I want to track the performance of a particular bit of code in a standardized way. I can write a method that takes a supplier and handles the performance tracking while calling the supplier and returning the result. This way tracked functions don't have a load of eg. timer initialization etc. If the supplier throws a checked exception, it should be caught and handled by the code that actually cares about the call, not the performance wrapper. Unfortunately, because of the way Java handles checked exceptions, I can't feed the supplier with a lambda or any other method reference that I'm aware of that throws a checked exception and let it be passed up to the original caller directly. So I need to catch my checked exceptions and wrap them in an unchecked exception to catch. Not pretty. There's probably something I'm missing but the language certainly doesn't go out of its way to help with this sort of thing.
- seppel 6y ago
  Java's checked exceptions pretty much died when they introduced lambdas. They don't work well together, at least not in the java type system. Further, I'd say that IndexOutOfBoundsException can happen pretty much everywhere, so it does not make much sense to make it a checked exception anyway.
  - twic 6y ago
    > Further, I'd say that IndexOutOfBoundsException can happen pretty much everywhere, so it does not make much sense to make it a checked exception anyway. Indeed. I don't know of any programming languages in which out-of-bounds array access is an error whose handling is enforced by the type system (checked exception, result, etc). Ditto for numeric overflow and division by zero. I believe even Ada doesn't force error handling of these.
    - fiddlerwoaroof 6y ago
      It’s a bit different, but languages like Idris have type systems that can prevent out of bounds array access. I’d be interested in seeing what the exception handling equivalent is.

fiddlerwoaroof 6y ago

Yeah, from a static safety perspective, Java’s checked exceptions are a big missed opportunity: if Java could have figured out a better syntax for them that was less annoying to deal with they could have been really interesting. As it is, they actively prevent certain sorts of abstractions.

MaxBarraclough 6y ago
> they actively prevent certain sorts of abstractions. Like what?
- fiddlerwoaroof 6y ago
  It’s been a while, but every time I’ve tried to mix higher order functions and checked exceptions in Java, I’ve found it pretty painful: there’s some annoying type checking issue around the way lambdas work in Stream.map or similar. Maybe I’ll come up with a demo when I’m back at my desk.
  - hyperpape 6y ago
    The lambda design team knew this was a pain point, and considered some designs that could've alleviated the problem (http://mail.openjdk.java.net/pipermail/lambda-dev/2010-June/001484.html http://mail.openjdk.java.net/pipermail/lambda-dev/2010-June/...). I think they decided it wouldn't work well, but it's at least possible to do things here. That said, I think the decision to do lambdas the way they did tacitly killed checked exceptions.
- jrimbault 6y ago
  You can't have an interface implementation throw exceptions not declared in the interface, hence all implementations of a given interface have to declare the same failure modes. And then everything is nicely coupled.
  - kllrnohj 6y ago
    A great example of this is ByteArrayOutputStream's close(). It's documented to do literally nothing, and yet you still have to "handle" an IOException that will never, ever happen. https://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html#close() https://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayO...
    - hyperpape 6y ago
      The language doesn't force them to do that--they could override the interface and not declare the Exception. Then if you were working with an object declared to be ByteArrayOutputStream, you wouldn't need to handle the Exception. If working with the interface, you would, because that's the point of an interface.
      - twic 6y ago
        Yes, this is a poor example. The declaration of that exception is either a mistake, or a way of reserving some wiggle room for future changes.
  - hyperpape 6y ago
    This is backwards of how I think about it, so I'm curious what you're thinking. If an implementation of an interface can throw an exception that its interface doesn't declare, that breaks the abstraction. How can you safely use the interface? You either have to catch Exception (which is effectively the same as wrapping every exception in some InterfaceException class), or give up on handling any Exceptions thrown by the interface.
    - jrimbault 6y ago
- ThorinJacobs 6y ago
  I've run into this when working with lambdas in particular. Say for instance I want to track the performance of a particular bit of code in a standardized way. I can write a method that takes a supplier and handles the performance tracking while calling the supplier and returning the result. This way tracked functions don't have a load of eg. timer initialization etc. If the supplier throws a checked exception, it should be caught and handled by the code that actually cares about the call, not the performance wrapper. Unfortunately, because of the way Java handles checked exceptions, I can't feed the supplier with a lambda or any other method reference that I'm aware of that throws a checked exception and let it be passed up to the original caller directly. So I need to catch my checked exceptions and wrap them in an unchecked exception to catch. Not pretty. There's probably something I'm missing but the language certainly doesn't go out of its way to help with this sort of thing.
seppel 6y ago
Java's checked exceptions pretty much died when they introduced lambdas. They don't work well together, at least not in the java type system. Further, I'd say that IndexOutOfBoundsException can happen pretty much everywhere, so it does not make much sense to make it a checked exception anyway.
- twic 6y ago
  > Further, I'd say that IndexOutOfBoundsException can happen pretty much everywhere, so it does not make much sense to make it a checked exception anyway. Indeed. I don't know of any programming languages in which out-of-bounds array access is an error whose handling is enforced by the type system (checked exception, result, etc). Ditto for numeric overflow and division by zero. I believe even Ada doesn't force error handling of these.
  - fiddlerwoaroof 6y ago
    It’s a bit different, but languages like Idris have type systems that can prevent out of bounds array access. I’d be interested in seeing what the exception handling equivalent is.