<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Archie,<br><br>Thank you for your response!<br><br>> complicated, tree-like control flow & logic data structure<br>> ...<br>> in Java you have to convert it into a linear sequence<br>> ...<br>> So in a sense the real "problem" you are addressing is<br>> that we're trying to jam a tree/graph data structure into<br>> a linear sequence.<br><br>I actually addressed this in my original post.<br><br>Long story short, my solution is not meant to take an existing construct and replace it with something simpler or more concise. It's meant to let 2 or more statements that throw the same exception to be handled in different ways while staying in the same scope. It's meant to communicate a clear intent and demonstrate a relationship between 2 statements that otherwise is not immediately obvious. It's like an if-else statement vs a ternary operator. The fact that it is more concise is a side effect.<br><br>Furthermore, nothing is being replaced here. If you are forced to make a logical control flow decision based off of an exception being thrown (fetch data model A, but if exception, then use default data model), then my solution is not something you should be using. The existing try catch blocks and the ways we use it meet that need. John's example above is a good demonstration of how to handle control flow via exceptions, if we are forced to make logical control flow decisions based on exception results.<br><br>> Could the Java language be "compressed" in various ways<br>> so that we have to type fewer characters?<br><br>I have 0 desire to make this language more concise, especially when we are talking about exceptions. Exceptions are where I want things to be clear and obvious. I am making this post because my current codebase is doing exactly what you and John are suggesting, and our readability is suffering because of it. I am trying to find a way to address that, and this just happens to be the solution I landed upon.<br><br>I should also add -- I landed on this solution by thinking about how best to communicate a relationship. 2 statements throw the same exception, but should be handled in different ways. The happy path control flow does not depend on the exception, we just want to handle the failure and deal with it in a way that communicates how statements relate to each other. How best to accomplish that? Well, we use blocks in Java to communicate relationships between statements. The try block gives us one for free. And we use catch blocks to communicate exceptional control flow. It is meant to truly be exceptional, so we should avoid putting logical control flow there unless necessary. And if necessary, best that we wrap the whole statement in a single try catch block. But what about the remainders? Not all exceptions touch control flow, at least not in any meaningful way. Sometimes, we just want to "fail more gracefully". And indeed, we should strive for that. One of the best examples of failing gracefully is to wrap an exception with a more helpful exception that communicates the problem better. And if we can communicate relationships between failures more easily, then our code is all the better for it.<br><br>> The philosophy behind the design of Java (as far as I can<br>> infer it) is to prioritize logical clarity, not brevity.<br>> So we stop when we get something that is reasonably<br>> adequate.<br><br>Well by that logic, this post I made is necessary. The existing solution is certainly not adequate for me because logical clarity is stretched and strained across multiple block scopes that have nothing communicating how they relate to each other. I see one way to make things adequate, so I am making a post. And I think it is a good solution because it blends in well with what Java is already doing in other contexts, let alone for exceptions. Again, I consider this solution akin to an if statement vs a ternary operator.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you both for your time!</div><div class="gmail_default" style="font-family:monospace">David Alayachew<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 3, 2023 at 12:23 PM 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 Sun, Dec 3, 2023 at 11:01 AM David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:</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 style="font-family:monospace">Here are some thoughts I had about Checked Exceptions, plus an idea.<br></div></div></blockquote><div><br></div>Some random thoughts/opinions on this idea...<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Let's take the big picture view. Writing Java source code is basically a serialization exercise: in your head you have some complicated, tree-like control flow & logic data structure but to express that in Java you have to convert it into a linear sequence of UTF-16 codes.</div><div class="gmail_quote"><br></div><div class="gmail_quote">So in a sense the real "problem" you are addressing is that we're trying to jam a tree/graph data structure into a linear sequence. As a result, there's never going to be a "pretty" way to do it, only different ways of doing it adequately.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">In other words, the best we can hope for is something well-defined and unambiguous that everyone can understand and agree on, and then get on with our lives. And that's what we already have.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Could the Java language be "compressed" in various ways so that we have to type fewer characters? Yes! There are lots of ways to do that, including your suggestion. Another idea is that we could replace "class", "interface", and "protected' with "cls", "infc", and "prtd". But where do you stop? And what is your criteria for stopping?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The philosophy behind the design of Java (as far as I can infer it) is to prioritize logical clarity, not brevity. So we stop when we get something that is reasonably adequate.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">As has been said before: "If what you want is a language for algorithm compression, try Perl" :)<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">-Archie<br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</blockquote></div>