Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can actually use a generic parameter in a throws clause, so you can write something like:

    interface FunctionThrows1<S, T, E1 extends Throwable> {
      T apply(S in) throws E1
    }
    interface FunctionThrows2<S, T, E1 extends Throwable, E2 extends Throwable> {
      T apply(S in) throws E1, E2
    }
    ...
But you still have to write one version of your method for each arity of throwing that you want to be able to wrap.


Interesting. I tried this years ago, and it never worked. Maybe that's changed in recent versions? Arity versions are still more feasible at least, and many languages are willing to pay the cost for them.


AFAICR this has always worked. But you rapidly run into limitations - as i say in another comment, catch and throw are not themselves generic. Plus, none of the interfaces used in the streams API have exception parameters.


> Plus, none of the interfaces used in the streams API have exception parameters.

That's partly because there's another problem. Potentially, you could have streams of the form, say, `...map(A::foo).map(A::bar).map(A::baz).collect(...)`, and each of foo, bar, baz adds another exception type to the set that can be thrown by collect.


Result/Either-based streams have exactly the same problem. An exception-supporting stream API would solve it the same way: a function can either throw no exception, or an exception of the same type as thrown by a previous operation. You could have a .mapException operation which could change the exception type, like Result::map_err in Rust.

In practice, you would end up with the stream throwing an exception of some general type (in 95% of cases, IOException!), but you could still write specific catch blocks for each possible subtype.


Let me put it this way: the message I got from the language team is that the problem is certainly acknowledged, and various alternatives to dealing with it are known, but none of them has so far been shown the clearly preferable, "good" choice, so until one presents itself, the decision is to do nothing rather than add/remove features that could later have other negative consequences.


Maybe that was it. That means there's no way to generically remove or translate the exceptions, e.g. by wrapping it into a runtime exception, or into a specific Either value based on the exception type.


Yeah, I'm pretty sure there were some compiler bugs involving generic exceptions around 1.5 - 1.6. (I don't know if they ever got fixed -- I switched to Kotlin.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: