Try/Catch DU Exception

[Attila Kelemen]

>
> Hmm.. this is starting to sound a little out of bounds. If using Kotlin
> creates some new danger that wasn't there before, how is that Java's
> problem?
>
> And in any case, wouldn't you already have a similar issue in any normal
> try/catch scenario with respect to Java's checked exceptions?
>
>     obj.method();   // might call kotlin and throw IOException??
>     try {
>         in.read();
>     } catch (IOException e) {
>         // handle exception
>     }
>

In my opinion, anything that can be done in the byte code is Java's problem
because when it links against something then it links against a bytecode.
Java just has to balance on what is the consequence of ignoring something
that is a possibility at bytecode level.

So, the issue is different, because the consequences are different. If a
method throws an undeclared checked exception, then it is awkward (and
maybe annoying to some degree if you want to catch that exception) but it
is generally not a big deal because almost always you just want to rethrow
the exception. And as for handling a specific exception: It is probably
already a futile attempt because it is unlikely that you are able to
distinguish enough between the exceptions. I think a better example for a
problem would have been this (I would consider this currently the worst
case):

```
try {
  obj.method(); // might call kotlin and throw IOException??
  in.read();
} catch (IOException e) {
  // handle exception
}
```

Because in the above example, one might have been fooled into believing
that it is handling a specific failure when in fact it might be something
else. This can be bad but I believe (I have no statistics of course), that
when people handle exceptions, then either they wrap around a single call
when want to handle a specific exception, otherwise they don't really have
an exact idea about the exception anyway, so they almost certainly wanted
to catch that exception as well.

On the other hand: A local variable taking a value that was never assigned
to it (and btw. this implies a change to the memory model as well) is
extremely surprising. And being extremely surprising is bad because when
people are looking for the root cause they are very likely to not even
think about this possibility. Making the bug hunt a lot more horrible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240715/95e916d2/attachment.htm>