Checked exceptions

Wed Oct 16 02:42:16 UTC 2019

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Andrew Haley" <aph at redhat.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Mardi 15 Octobre 2019 20:06:51
> Objet: Re: Checked exceptions

> There are two questions here:
> - Are checked exceptions, in fact, a failed experiment?
> - If so, is there something that can be done about it?
> 
> The first is, as StackOverflow would say, “primarily opinion-based”, and
> opinions run strong and varied.  (PLEASE DO NOT weigh in with your opinion on
> this here; that’s not the point, and it wouldn’t be helpful.  All the opinions
> are on the record thousands of times over.)  There are surely some — even many
> — who believe strongly that checked exceptions are a failed experiment.  And I
> don’t want to say these people are wrong — it’s their opinion — but in my
> discussions with them, they are nearly universally wrong about one thing: *they
> all assume that everyone agrees with them.*  And that is completely wrong.
> 
> We had a dramatic demonstration of this at an Ask the Architects at Devoxx a few
> years ago, when the topic came up.  It was clear what the opinion of the asker
> was (“When are you guys going to get rid of checked exceptions already”), and
> also clear he thought that this was “settled case law.”  So we did a show of
> hands, and found (in this particular audience), that about 20% of the audience
> thought CEs were definitely a failed experiment, and about 40% of the audience
> was willing to raise their hand to something like “They’re not great, but
> they’re not the end of the world, and I am pretty much able to get on with my
> life.”  The moral of this story was: when the only voices you hear vocally are
> “X sucks”, it’s easy to mistakenly assume the whole world thinks the same, when
> in fact its just a vocal minority, and there’s a silent majority who doesn’t
> fully agree but doesn’t want to argue, and would rather just  get on with their
> work.
> 
> We saw something similar, by the way, when we did local variable type inference.
> For years, we heard people consistently asking for it, but as soon as we did
> it, a vocal counter-faction came out of the woodwork to declare that this was
> the dumbest thing they ever heard.  Again, moral of the story is, don’t assume
> that your opinions are universally held, *even if you can’t find anyone to take
> up the opposite position.*
> 
> On the other question, even if we assume that checked exceptions are a failed
> experiment (and my discussions with developers do not bear this out as being a
> settled question), and therefore we would do something different if we were
> starting over, would the cure be worse than the disease to try and change
> course now.  And, as Andrew states, “it’s hard to see a good way to transition
> away from them.”
> 
> IMO, I think the problem is not so much with the concept of checked exceptions
> in general, but with the fact that many libraries — especially those developed
> early in the game — used them inappropriately, and in ways we wouldn’t were we
> doing those libraries now.  The good news here is that it’s easier to do new
> libraries than to change the underpinnings of the programming model, so over
> time, this problem may resolve itself.  (Though, IOException will likely be a
> thorn in our side forever.)
> 
> The one case where it is indeed painful — and where we would most likely
> consider doing something — is with the interaction of exceptions and lambdas,
> which I understand is painful for people.  But, there’s a good reason we
> haven’t done something about this yet — we don’t know what the right thing is.
> We tried exploring a form of exception transparency, which seemed initially
> promising, but turned out to be flawed.  We then tried another direction, which
> was promising and looked to be sound, but extremely complex.  We’ve invested a
> great number of expert-hours in the problem, and we don’t yet have a solution
> that doesn’t suck, so we haven’t done anything yet.  But there are developments
> on the horizon that might enable us to take another run at the problem, so I
> wouldn’t count it out yet.

We have collectively spent more time that it's reasonable trying to come with a local solution for exception transparency,
and i don't believe there is one (apart restricting how lambda can escape like in BGGA).
There is a lot of clues inside the JDK itself that people wrestle with checked exceptions in their day to day job.
You have UncheckIOExcpetion and IOError to take an IOException and wrapped it in an unchecked one,
you have Thread.currentThread().interrupt() which is an ad hoc way to avoid throwing InterruptedException but still propagate it,
you have Unsafe.throwException, you have the trick to use an raw type to throw a checked exception. And i'm sure i miss some others.

Fundamentally, checked exceptions are a leaking abstraction because it's function coloring [1],
you can not compose a function with a checked exception with a function without a checked exception.

The other serious issue with checked exceptions is that people don't understand Java exceptions because of checked exceptions. You see a lot of catch blocks that doesn't recover on the error but fallthrough to the the instruction fater the catch block. And because exceptions are exceptional, the catch block is usually not much exercise by the tests so it leads to brittle software.
That's our 1 billion dollar mistake. Java program are less safe that their C#, Scala, Kotlin counterparts because of that.
In that context, asking to Java developers if the grass is greener on the other side only works if they know the other side.

You have acknowledged that since we have introduced lambdas, it's now worst because it's now easier to do function composition, so people run into the function coloring problem more often.
It seem that in the future, we will add more ways to do function composition, and that's a good thing, but the problem of checked exceptions will be more glaring. 

By example, Loom doesn't require users to annotate a function that does an async call, so yeah, no coloring function problem unlike with Kotlin or JavaScript but if you actually want to use the Continuation API, you still have an API with checked exceptions that make async/join non composable. Another example, recently, a new branch was added to amber to study how to add local functions, function in function like in JavaScript, to Java, again, this will ease function composition.

Because of that, our future is a little darker than it should.

Rémi

[1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ 

> 
> 
> 
> 
> 
>> On Oct 15, 2019, at 5:00 AM, Andrew Haley <aph at redhat.com> wrote:
>> 
>> On 10/14/19 11:45 PM, Ryan Schmitt wrote:
>> 
>>> I'm curious to know what the current thinking is on checked
>>> exceptions. Is there agreement that the current situation is less
>>> than ideal? If so, how might they be addressed, and are they even
>>> enough of a problem to be worth addressing?
>> 
>> Opinions are divided, but when you ask experienced OpenJDK developers
>> about their least-favourite Java feature, checked exceptions are
>> likely to be high on the list. In hindsight, it would have been better
>> not to have them, at least in this form.
>> 
>> However, it's hard to see a good way to transition away from them. I
>> suppose we could simply declare exception specifications to be
>> optional in some future Java release, but it would be substantial work
>> for a lot of people and we'd have to very carefully review the
>> compatibility implications.
>> 
>> --
>> Andrew Haley  (he/him)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> https://keybase.io/andrewhaley
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671