Checked exceptions

[Brian Goetz]

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