Ah, that's because java generics don't work with exceptions.

In Java, the concept of exceptions is incompatible with the concept of parametrized types.

During compilation, type parameters are erased. "T" becomes "Object"; "T extends Something" becomes "Something"; assignment becomes type conversion. But at the end it works correctly. If you try to make something that wouldn't survive the type parameter erasure -- such as having two methods with the same name, one of which accepts "List<String>" and another accepts "List<Integer>" as their input -- it will be a compile-time error, because you can't have two methods with the same name and the same parameter "List".

But imagine that you have a type "MyException" extending RuntimeException, and your code has "catch (MyException)". After compilation, this would become "catch (RuntimeException)", which is wrong, because it would also catch other RuntimeExceptions, and it is not supposed to. But if you make this construction a compile-time error, then... the whole thing becomes useless, because what's the point of having an exception type you cannot catch.

On further thought I understood that streams usually are lazy and real exception would be thrown not at map, but later (probably in collect or similar method). So it would require to propagate that E generic parameter to almost every function (and Stream type signature). Also it won't work well with multiple checked exceptions. So yeah, not that easy.

This doesn't work if your function throws multiple checked exceptions.

if you have to do this in every step of the Stream then it seems like a failed design.

Another option is to fool the compiler. So-called sneaky throws. Something like

    public static void main(String[] args) {
        try {
            sneakyThrow(new IOException("io"));
            Test.<IOException>emulateThrows();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    static void sneakyThrow(Throwable e) {
        Test.<RuntimeException>sneakyThrow2(e);
    }

    private static <E extends Throwable> void sneakyThrow2(Throwable e) throws E {
        @SuppressWarnings("unchecked") E e1 = (E) e;
        throw e1;
    }

    static <E extends Exception> void emulateThrows() throws E {
    }

If they are officially bad, remove them from the language. It's a backwards-compatible change. Currently we are in a weird situation, when standard library does not work well with each other. It's like making iPhone without USB-C cable and Macbook without USB-A port.

Yes. One can workaround it with the throw-as-unchecked pattern: https://stackoverflow.com/questions/14038649/java-sneakythro...

I find checked exceptions interesting. They happen to be the only example of an effect system in a mainstream language. Anders Hejlsberg formulated the main argument against them here [1] Basically the problem is that checked exceptions are infectious and intermediary code needs to annotate all the exceptions of code that it calls. Which is a chore. Lucas Rytz states in his PhD thesis [2] that the problem is not wich checked exceptions themselves, but that in the java implementation 'not mentioning an exception means if won't happen'. He proposes a system where the default is 'any exception' and being able to turn it off with a compiler flag. And states that the developer experience of that would be much better. This may become possible in Dotty Scala using the effect system based on implicit functions. But that's in 'proposed' status.

[1]https://www.artima.com/intv/handcuffs.html [2]https://lrytz.github.io/pubsTalks/ the link to his thesis doesn't work anymore. I cherry pick some of it in my talk for a Scala meetup in Utrecht https://www.slideshare.net/yoozd/effect-systems-in-scala-bey...

That's what languages like Rust do with a return return type that is part of the core language.

Sometimes I wish Java had one too to complement Optional. I wonder what the argument against that is? Too much confusion with the existing Exception system?