Some thoughts and an idea about Checked Exceptions

[David Alayachew]

Hello Archie,

Thank you for your response!

> complicated, tree-like control flow & logic data structure
> ...
> in Java you have to convert it into a linear sequence
> ...
> 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.

I actually addressed this in my original post.

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.

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.

> Could the Java language be "compressed" in various ways
> so that we have to type fewer characters?

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.

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.

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

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.

Thank you both for your time!
David Alayachew

On Sun, Dec 3, 2023 at 12:23 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Sun, Dec 3, 2023 at 11:01 AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Here are some thoughts I had about Checked Exceptions, plus an idea.
>>
>
> Some random thoughts/opinions on this idea...
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> As has been said before: "If what you want is a language for algorithm
> compression, try Perl" :)
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231203/5c4900c7/attachment-0001.htm>