Hacker News Reader

Comment by aprinsen | Hacker News Reader

I didn't care for Java when I learned with it in school, found it verbose.

Working with it as a dev, my opinion improved. A lot of the new FP inspired APIs make logic much terser, and the OOP stuff can make implementing certain architectural patterns very clean.

The other great thing about Java is that nearly every conceivable question has been answered, as far as day to day development. Not so for newer languages.

My biggest pain point with java is the type system. Like, you basically need to write or consume a library to work with tuples.

View on HN

Stream API allows you to write fluent codes until you met checked exceptions. I wish they had solved this.

Java generics just aren't powerful enough to express that a higher order function's exceptions depend on its args, so pretty much everyone has given up on specific checked exceptions.

Yes, they are:

    @FunctionalInterface
    public interface ThrowingConsumer<T, E extends Throwable> {
        void accept(T value) throws E;
    }

    public static <T, E extends Throwable> void forEach(Collection<T> elements, ThrowingConsumer<T, E> consumer) throws E {
        for (T element : elements) {
            consumer.accept(element);
        }
    }

There is a significant shortcoming, which is that you can't catch exceptions using the type parameter - this does not compile:

    public static <T, E extends Throwable> Optional<E> forEach(Collection<T> elements, ThrowingConsumer<T, E> consumer) {
        for (T element : elements) {
            try {
                consumer.accept(element);
            } catch (E e) {                 // <-- not allowed!
                return Optional.of(e);
            }
        }
        return Optional.empty();
    }

You can kludge your way around that in various ways, but none of them are pretty.

Yeah, that sort of works, though I’m not sure a function that throws two distinct exception could be compatible with a generic method that takes functions throwing three distinct exceptions (that may sound crazy but some java.security crypto stuff does it).

Looking back on it now I think our revulsion to simply using "throws Exception" ought to be re-examined. In practice, while it's nice to know exactly what kinds of exceptions are being thrown it could be the emphasis on this actually holds us back. What's more important is whether an Exception could be thrown at all versus none.

You can bind unused parameters to RuntimeException! I'm not telling you you should enjoy doing this, mind, just that it's possible.

Reply on news.ycombinator.com