brian.goetz at oracle.com
Wed Oct 16 17:20:35 UTC 2019
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.)
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<http://clearwater-analytics.com/unsubscribe>.
More information about the jdk-dev