Retiring Checked Exceptions Was: Throwing Functions

[Brian Goetz]

A brief reminder: this is getting out of the charter of amber-dev.



On 11/14/2022 5:58 PM, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Archie Cobbs" <archie.cobbs at gmail.com>
>     *To: *"Nathan Reynolds" <numeralnathan at gmail.com>
>     *Cc: *"Brian Goetz" <brian.goetz at oracle.com>, "John Hendrikx"
>     <hjohn at xs4all.nl>, "Remi Forax" <forax at univ-mlv.fr>, "amber-dev"
>     <amber-dev at openjdk.org>, "amber-spec-experts"
>     <amber-spec-experts at openjdk.java.net>, "Ron Pressler"
>     <ron.pressler at oracle.com>
>     *Sent: *Monday, November 14, 2022 5:33:35 PM
>     *Subject: *Re: Retiring Checked Exceptions Was: Throwing Functions
>
>     On Sat, Nov 12, 2022 at 5:26 PM Nathan Reynolds
>     <numeralnathan at gmail.com> wrote:
>
>         > I've found that there are a lot of people out there who
>         quietly think checked exceptions are ... pretty OK.
>
>         Count me in this camp.  Checked exceptions are so much better
>         than error return codes.
>
>
>     I like checked exceptions also.
>
>     But so what? Of course everyone including me is going to have some
>     opinion... the deeper question is, what are we trying to optimize
>     for in a programming language?
>
>     Well I'm sure everyone has an opinion on that question as well..
>     but at least that question is a little closer to the heart of the
>     matter.
>
>     A problem I've seen with programming language design happens in
>     other fields as well. Consider building architecture for example.
>     Architects can sometimes drift from optimizing for the humans that
>     will occupy the space (what should be their goal) to optimizing
>     for simplicity, beauty, and elegance (what they really want to be
>     their goal).
>
>     Simplicity, beauty, and elegance are all well and good until they
>     start detracting from the more important goal of serving the
>     humans. Have you ever had dinner in a nice restaurant that has
>     sleek & beautiful architecture, but because of all the open space
>     it's really drafty and because of the hard concrete ceilings and
>     resulting terrible acoustics you can barely understand what anyone
>     across the table is saying? (yes, that just happened a few weeks ago)
>
>     So here's my opinion on what we should be optimizing for, from my
>     own little perspective.
>
>     I'm not a language designer (those folks are a lot smarter than me
>     :) I'm just a regular Java user for 20+ years. My main development
>     responsibility right now is an enterprise web application with
>     ~150,000 lines of code, plus millions of LOC incorporated by
>     reference (Spring, Hibernate, Tomcat, Linux, etc.).
>
>     But the windows on my screen are only ~54 lines tall.
>
>     That means I can inspect at most 0.03% of the code at any one
>     time, and yet I'm supposed to somehow ensure this whole thing
>     works properly without any bugs.
>
>     Therefore, to me the most important property of a programming
>     language is this: how hard is it to look at a chunk of code on the
>     screen and be able to convince myself that it will do what it's
>     supposed to and not contribute any bugs?
>
>     Is most of the critical information there in front of me? Can I
>     convince myself I'm looking at a seaworthy vessel of logical
>     correctness?
>
>     Or are there a bunch of "leaks" that I either have to patch, or
>     (almost worse) do a bunch of research to finally realize that in
>     fact they really aren't leaks after all?
>
>     How hard is it to hunt down the information that's not explicitly
>     on the screen that I need to feel confident in what I'm looking at?
>
>     No doubt Java would be more simple, beautiful, and elegant without
>     checked exceptions. But checked exceptions are explicit
>     information on the screen relating to what error cases can
>     possibly occur. They appear pretty much when and where you need to
>     see them. And the compiler guarantees that you won't accidentally
>     miss one.
>
>     From the perspective of "Help me prove this code is correct and
>     handles all the possible error cases" what's not to love about that??
>
>     Features that help my cause:
>       - Compile time explicit strong typing
>       - Precisely defined semantics (compare to C: order of execution,
>     memory model, etc.)
>       - Easily accessible Javadocs that specify behavior precisely
>       - Compiler warnings
>       - @Overrides
>       - Checked exceptions
>
>     Features that don't help my cause (they're not bad, they're just
>     less important):
>       - Anything that optimizes for the speed of writing code rather
>     than the speed of reading it
>       - Anything that optimizes for code brevity (if that were the
>     goal, we'd all be using perl!)
>
>     An example of the latter is the new "var" keyword. Yes it makes it
>     faster to WRITE code, but it makes it a tiny bit slower to READ
>     code. It means to understand what "foo" is, I have to do one
>     little tiny extra step of type inference in my head. Not a big
>     deal, and I'm certainly not opposed to the feature, but I probably
>     won't use it much.
>
>     Java's "target market" as it were is large enterprise projects.
>     Regarding such projects, a wise person once said: /You write code
>     once, but you maintain it forever./
>
>
> What if checked exceptions work like unchecked casts ?
>
> What if instead of a compiler error you still have a warning when you 
> suppress a checked exception, so you can write code like this
>
>   public void m() throws IOException {
>     var input = ...
>     Runnable runnable = () -> {
>        input.read();
>     };
>     runnable.run()
> ;  }
>
> and you get two warnings, one because you have suppressed the 
> IOException inside the Runnable and one because you have a throws 
> IOException with no IOException thrown inside the body of m() ?
>
> So IOException will work seamlessly with streams, methods that takes 
> lambdas, etc.
>
>
>
>     -Archie
>
>     -- 
>     Archie L. Cobbs
>
>
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221114/71e1b18a/attachment-0001.htm>