Checked exceptions

Thomas May tmay at clearwateranalytics.com
Thu Oct 17 17:58:16 UTC 2019


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>.


More information about the jdk-dev mailing list