Checked exceptions (original) (raw)

Brian Goetz brian.goetz at oracle.com
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 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 (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 XmlParser.convert(InputStream i, Class 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.  But I realize that isn't possible without a lot of breakage, so what about instead a optionalParseDouble that returns a Optional? > 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>.

More information about the jdk-dev mailing list