mrjarviscraft at gmail.com
Wed Oct 16 19:05:33 UTC 2019
Does not look fine, and the problem is not in the mouthfulness. There is
just too much stuff happening behind the scenes: Scanner allocation, Stream
allocation, duplicate analyzis of the source String (one to make sure it is
a number, another to have it parsed, which may be practically the same). It
is the same as in current parseInt(String) which is fine when the data
provider can guarantee that the source String is a valid number, but cannot
be used effectively when non-number input is expected and should be handled
normally (because it will require exception object allocations, stack-trace
filling and exception-table stuff in the caller). As for me, things like
parseOptionalInt(String) and/or parseInt(String, int defaultValue) should
definitely appear in the API.
ср, 16 окт. 2019 г., 21:39 Remi Forax <forax at univ-mlv.fr>:
> ----- Mail original -----
> > De: "Brian Goetz" <brian.goetz at oracle.com>
> > À: "Thomas May" <tmay at clearwateranalytics.com>, "jdk-dev" <
> jdk-dev at openjdk.java.net>
> > Envoyé: Mercredi 16 Octobre 2019 19:20:35
> > Objet: Re: Checked exceptions
> > I think there has already been a trend in newer APIs towards using fewer
> > checked exceptions. It's one of those things that is harder to notice,
> > because no one plants a big red sign saying "I was thinking of using
> > seven kinds of checked exceptions here, but then decided against it."
> > The question surrounding `Double::parseDouble` is a different one,
> > though; whether it is better to use the null object pattern to signal
> > failure than using an unchecked exception. In this case, you can make a
> > reasonable argument that the only way it fails in a way that the caller
> > might care about is if the string didn't represent a double, and the
> > error message that would come with the exception isn't really helpful,
> > so the null object pattern here is an acceptable alternative.
> > Again, I think you'll find that newer APIs are leaning in this direction
> > too. And again, I think it's just hard to notice when things are
> > getting incrementally better.
> > As to curing the existing disease, I suspect the horse has mostly
> > escaped the barn. (Yes, "fixing" _this one issue_ isn't hard, thought
> > even the bikeshed over naming it would likely dwarf the benefit. But
> > more importantly, once we start, we've implicitly committed to "fixing"
> > all of them, and the related stream of "You did it here, why don't you
> > do it there" requests is extremely disruptive. So we tend to look at
> > this sort of change with a broader focus.)
> I just want to add that java.util.Scanner introduce in 1.5 is the "modern"
> version of parseDouble,
> you can initialize a Scanner with a String and use
> hasNextDouble/nextDouble (and set the Locale to choose the input format).
> so if you want an OptionalInt from a text, you can write
> Stream.iterate(new Scanner(text), Scanner::hasNextInt, s ->
> mouthful but it works :)
> > On 10/15/2019 4:15 PM, Thomas May wrote:
> >> So, assuming that checked exceptions are here to stay (right or wrong).
> >> Would it be an option to start adding new APIs to the JDK with either no
> >> exceptions or unchecked exceptions?
> >> 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>?
> >> Or is this too much effort for the gain?
> >> ________________________________
> >> NOTICE: This e-mail message, together with any attachments, contains
> >> 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
> >> delete it. The information we provide is from sources Clearwater
> >> considers reliable, but Clearwater Analytics provides no warranties
> >> 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
> >> 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