Design / Question: Why doesnt CheckedSupplier use Generics / Why is there even CheckedSupplier and Supplier

[StefanLobbenmeier]

I was just writing code like this in another project:

class Scratch {
    public static void main(String[] args) {
        String a = get("A"::toString);
    }
    static <T, E extends Exception> T get(CheckedSupplier<T, E> supplier) throws E {
        return supplier.supply();
    }
    interface CheckedSupplier<T, E extends Exception> {
        T supply() throws E;
    }
}

Using Generics for the Exception allows the main method to use CheckedSupplier with lamdas that do not throw an Exception. So in other words my own declaration of CheckedSupplier can be used in any cases CheckedSupplier is used or Supplier is used (right?)

So I was wondering why this is not also done in this library. Is there a good reason not to use these Generic Exceptions? I always thought it was a bit too complicated having to change the type from and to Supplier / CheckedSupplier when an Exception is added / disappears.

[danieldietrich]

We could ask the Java language architects the same question.

In Vavr, we wanted to have the simpler signature because we use io.vavr.control.Try to encapsulate exceptional cases.

[StefanLobbenmeier]

I see - So I guess using Generics in the Checked Supplier would then also have to extend to Try, e.g. for the get() and getCause methods here: https://github.com/vavr-io/vavr/blob/a09f8cc3ade42677143f5c34329573fc24210bd7/src/main/java/io/vavr/control/Try.java#L629

But I understand that this is not as easy. For me the main motivation was being able to use the retry functionality of resilience4j (which uses this library a lot) and not having to catch Throwables.

But definetly thanks for answering the questions 😄