Checked exceptions

[Brian Goetz]

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 
method-that-throws-exception.



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 oracle.com>
> *Sent:* Thursday, October 17, 2019 10:17 AM
> *To:* Thomas May <tmay at clearwateranalytics.com>; 
> jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
> *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 <http://clearwater-analytics.com/unsubscribe>.