<div dir="ltr"><div>These are great points!</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 14, 2022 at 9:33 AM Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sat, Nov 12, 2022 at 5:26 PM Nathan Reynolds <<a href="mailto:numeralnathan@gmail.com" target="_blank">numeralnathan@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> I've found that there are a lot of people out there who quietly think checked exceptions are ... pretty OK.</div><div><br></div><div>Count me in this camp.  Checked exceptions are so much better than error return codes.</div></div></blockquote><div><br></div><div>I like checked exceptions also.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div><div class="gmail_quote">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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">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)</div><div class="gmail_quote"><br></div></div></div><div class="gmail_quote">So here's my opinion on what we should be optimizing for, from my own little perspective.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">But the windows on my screen are only ~54 lines tall.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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?</div><div class="gmail_quote"><br></div><div class="gmail_quote">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?</div><div class="gmail_quote"><br></div><div class="gmail_quote">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?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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?</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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??<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Features that help my cause:</div>  - Compile time explicit strong typing<div class="gmail_quote">  - Precisely defined semantics (compare to C: order of execution, memory model, etc.)<br></div><div class="gmail_quote">  - Easily accessible Javadocs that specify behavior precisely</div><div class="gmail_quote">  - Compiler warnings</div><div class="gmail_quote">  - <a class="gmail_plusreply" id="m_-4393736174869020120plusReplyChip-0">@Overrides</a><br></div><div class="gmail_quote"><div class="gmail_quote">  - Checked exceptions</div><div class="gmail_quote"><br></div></div><div class="gmail_quote">Features that don't help my cause (they're not bad, they're just less important):</div>  - Anything that optimizes for the speed of writing code rather than the speed of reading it<div class="gmail_quote"><div class="gmail_quote">  - Anything that optimizes for code brevity (if that were the goal, we'd all be using perl!)<br></div><div class="gmail_quote"><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Java's "target market" as it were is large enterprise projects. Regarding such projects, a wise person once said: <i>You write code once, but you maintain it forever.</i><br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">-Archie<br></div><div class="gmail_quote"><br></div></div>-- <br><div dir="ltr">Archie L. Cobbs<br></div></div>
</blockquote></div>