Checked exceptions

Remi Forax forax at
Wed Oct 16 18:38:19 UTC 2019

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at>
> À: "Thomas May" <tmay at>, "jdk-dev" <jdk-dev at>
> 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 -> s).mapToInt(Scanner::nextInt).findFirst()

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