Patterns: Exhaustiveness, Unconditionality, and Remainder
openjdk.org
openjdk.org
We really need:
1 - expressive switch without default section,
2 - closed enums which aren't just dumb ints
3 - putting more emphasis on compile time safety instead of runtime
Whether you consider Dart a "mainstream" language is I guess an open question. :)
(I'll check it out. Thanks for sharing!)
It was not a genuine question. The genuine bits were in parentheses.
The example the author gives, throwing an error on the default section, is a bit contrived. I agree that exhaustiveness checks should be pushed into the compiler wherever possible and enums are generally less useful than they could be. That said, there are many, many times where you actually want to the use the default section in a switch statement.
Writing in a strongly typed language where you only have to match and handle a few special states out of many would be absolutely abysmal without a default. Even something straightforward like lexing/tokenizing a simple text based structure with things like comments or special metadata would get out of hand quickly. Yeah, syntax can help alleviate that somewhat, but it's still a lot of unnecessary boiler plate. Not to mention it makes the sections much easier to grok at times; "Here we only handle X, Y, and Z differently and we pass everything else along"
It might be worth rereading. Goetz/Bierman are not saying switch defaults are always useless, they are saying that they are often useless. My own experience as a daily Java programmer suggests that the example is not at all contrived - I'm constantly writing switch defaults that will never run.
> Writing in a strongly typed language where you only have to match and handle a few special states out of many would be absolutely abysmal without a default.
Personally, I would much prefer being explicit about which states the code was written to handle, and have the compiler guide me towards asserting that newly added states are valid.
This is nice. I’ve gotten into the habit of writing such a test after each `switch` statement, for the reasons described (to not disable an exhaustiveness linter warning by presence of a default clause). I just hope they make the exception a RuntimeException (like an IllegalArgumentException) rather than an Error (like a NoSuchMethodError).
However, one disadvantage of the new pattern is that you won’t be able to do your own custom “unexpected enum value” handling any more without also disabling the exhaustiveness check (when implementing it in a match-all clause), because the synthesized check would otherwise preempt it. This is kind of a drawback. There should be an extra syntax for defining a “future case” clause.
Well, if they use a dedicated new exception type, I guess you could catch that, check that it was thrown from the right place (i.e. not thrown from some call within the explicit switch case code), and then do your custom handling. But that would be quite ugly.