Checked exceptions

Brian Goetz brian.goetz at
Thu Oct 17 19:07:09 UTC 2019

Better than that, but not really prepared to throw open the syntax 
bikeshed yet -- would rather keep the discussion on the level of model 
rather than how it is expressed for now.

But, to give you the flavor, suppose we have a class:

     class StringHolder {
          private String s;

          // with a deconstruction pattern StringHolder(String s), 
however declared

Now, I can compose the StringHolder pattern with an integer-parsing pattern:

     if (x instanceof StringHolder(Integer.toString(int i)) { ... use i 
... }
                      ^ Outer pattern, conditionally produces String
                                   ^ Inner pattern, conditionally 
produces int

where `Integer.toString(int i)` is a pattern that targets strings and, 
if it matches, produces an `int`.

Regardless of the details, the point is that I think this is a better 
way to solve the problem of conditional extraction than 

On 10/17/2019 1:58 PM, Thomas May wrote:
> Reading over the current draft proposal, I'm not sure I see how that 
> might work.
> Would there be some sort of match operator that you could override?  
> Such as,
> String num = "1.23";
> if (new Pattern("#.##").convert(num) double val) {
>   print("Hi " + val);
> }
> If that's the case, what would convert return?  Maybe something like
> DoubleMatch
> or
> Match<T>
> (like IntStream, or DoubleStream).
> If that is the case, then it would be possible to extend the API in 
> useful ways.  We could make something like
> Match<T> XmlParser.convert(InputStream i, Class<T> type)
> and then use it like
> if (XmlParser.convert(i, Foo.class) Foo bar) {
> }
> Am I way off base here or are you thinking of something better?
> ------------------------------------------------------------------------
> *From:* Brian Goetz <brian.goetz at>
> *Sent:* Thursday, October 17, 2019 10:17 AM
> *To:* Thomas May <tmay at>; 
> jdk-dev at <jdk-dev at>
> *Subject:* Re: Checked exceptions
> CAUTION: External Email
> > 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
> double-parsing pattern.
> 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.
> ------------------------------------------------------------------------
> NOTICE: This e-mail message, together with any attachments, contains 
> information of Clearwater Analytics and/or its affiliates that may be 
> confidential, proprietary copyrighted and/or legally privileged, and 
> is intended solely for the use of the individual or entity named on 
> this message. If you are not the intended recipient, and have received 
> this message in error, please immediately delete it. The information 
> we provide is from sources Clearwater Analytics considers reliable, 
> but Clearwater Analytics provides no warranties regarding the accuracy 
> of the information. Further, nothing in the email should be construed 
> as legal, financial, or tax advice, and any questions regarding the 
> intended recipient’s individual circumstances should be addressed to 
> that recipient’s lawyer and/or accountant.
> Clearwater Analytics, 777 W. Main St, Boise, ID 83702
> If you prefer not to receive emails from Clearwater Analytics you may 
> unsubscribe <>. 

More information about the jdk-dev mailing list