Retiring Checked Exceptions Was: Throwing Functions

[Nathan Reynolds]

These are great points!

Can we start a Wiki page and get all the points for and against checked
exceptions?  Then when others come along, we can point them to the page and
they can add to the discussion instead of rehashing it.

On Mon, Nov 14, 2022 at 9:33 AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> 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.*
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221114/4e884909/attachment-0001.htm>