Hacker News Reader

Comment by mrighele | Hacker News Reader

You're matching with the result of the expression inside the switch, and in case of an exception the result is something being throw, not something being catched, so the chosen approach seems correct to me.

given the code

    Future<Box> f = ...
    switch (f.get()) {
        case Box(String s) when isGoodString(s) -> score(100);
        case Box(String s)                      -> score(50);
        case null                               -> score(0);
        case throws CancellationException ce    -> ...ce...
        case throws ExecutionException ee       -> ...ee...
        case throws InterruptedException ie     -> ...ie...
    };

I read the above as

"if f.get() is a Box(...) then ..."

"if f.get() is null then ..."

"if f.get() throws ExecutionException then ..."

View on HN

Further bikeshedding this, since the JEP admits regular clauses and Exception clauses should be kept separate as they are treated differently, we could as well retain the original catch syntax:

    switch (f.get()) {
        case Box(String s) when isGoodString(s) -> score(100);
        catch InterruptedException ie           -> ...ie...
    };

Current try/catch gymnastics are laborious, requiring blocks making usage unwieldy in otherwise-one-line lambdas. Requiring "case throws" is yet more useless syntax inflation. It would be nice to keep things streamlined this once.

Yeah, reusing `catch` was also the first thing that came to my mind. The "case throws" feels awkward even though I can see why it's proposed (can be read as "in case (it) throws)

catch clauses in try/catch are also matching something being thrown.

People don't have problem reading try/catch, are used to it, it's already there, semantics match - why complicate things?

Case is better read as "captures ... [when ...]" and "case catch" simply means capturing an exception - the same way as try/catch does it.

If you flip it around - if somebody would do an experiment where they'd ask 100 developers to imagine that java supports catching exceptions in switch statements my bet is that almost all, if not all would write it as "case catch ...".

And there is really nothing fundamentally wrong with that. You can't catch catch handler, you can only catch an exception.

> People don't have problem reading try/catch, are used to it, it's already there, semantics match - why complicate things?

We don't have a problem reading try/catch because it comes from an era when Java was more procedural and less functional. "case throws" makes more sense in the functional-style Java era. (Well, makes more sense to me at least)

EDIT: To clarify "catch" is a verb and contains a block of executable statements. "case throws" maps to an expression (because I assume most people writing new code that uses this will be using switch expressions, not switch statements) In this context, "case throws" is a better choice because you are talking about the _expression_ inside the "switch".

Reply on news.ycombinator.com