brian.goetz at oracle.com
Thu Oct 17 16:17:33 UTC 2019
> The example that comes to mind is Double#parseDouble. It's annoying to have to deal with NumberFormatException, the API would jive better if instead it returned an Optional<Double>. But I realize that isn't possible without a lot of breakage, so what about instead a optionalParseDouble that returns a Optional<Double>?
Stepping back from the exceptions question for a minute, the way I would
prefer to address problems like this is via pattern matching. If we
expose a pattern whose target is a string, and which produces a binding
variable of type double if the string is the string representation of a
double, then either the pattern matches and produces a valid double, or
it doesn't match. The advantage of this over the Optional approach is
that is nestable with other patterns, so if we have a pattern that
produces a String, we can compose it (via nesting) with the
Once we have pattern matching, it will make sense to expose all sorts of
parsing patterns, which work similarly to the Optional-bearing version
of your method, but compose better.
More information about the jdk-dev