Checked exceptions

Thu Oct 17 05:47:31 UTC 2019

I like Rusts model. Returning Result<T, E> which is either Ok(T) or Err(E).
This effectively makes checked-exceptions the norm, as any method that can
fail will be returning a Result, requiring that you test for success rather
than assuming it.

In Rust, Result is a tagged union of an enum value (Ok or Err) as the tag
and T or E as content. When Java gets value-types I hope it will be within
reach to support this form of enum... Of course Rust has had to add other
features to make this not be cumbersome for Result (the try operator and
conversion via the From<T> and Into<T> traits, and some generic
specialisation of collections over Result) but these tagged unions have
other uses too.

>From what I've seen since Java 8 with lambdas and Streams really took off,
is that code appears to have become more brittle. Developers seem to have
largely opted for RuntimeExceptions to make APIs more usable in
composition, sometimes forgetting to document those exceptions, and users
have been less and less diligent about handling all documented exceptions -
since they now must refer to documentation and not code for the list of
exceptions they should cope with. Cleanup has become lazier, treating
exceptions with a broader brush, exceptions that are recoverable are
collectively treated as unrecoverable, or eliding the effort to transform
exception types into something appropriate to the context of the API
(leaking implementation details).

With so much lazy avoidance of checked exceptions, checked exceptions might
well be a less encountered issue, but the alternative isn't resulting in
better code.

If Java didn't have the legacy it has in such a huge API surface, and was
going to consider removing checked exceptions, it might have been better to
promote a move from exceptions in general (leaving Error) and embracing
Rusts more functional approach to communicating failure - unfortunately I'm
not sure that there's a nice path in that direction for Java now without
going through Python3 levels of migration pain.

--
Aaron Scott-Boddendijk

On Wed, Oct 16, 2019 at 3:43 PM Remi Forax <forax at univ-mlv.fr> wrote:

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