Try/Catch DU Exception

[Archie Cobbs]

On Sun, Jul 14, 2024 at 12:56 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> Also, I don't see the point of distinguishing between checked and
>>> unchecked exceptions. Because technically it is possible for a method to
>>> throw any exception. So, as for method calls I would just say that a method
>>> call may throw any exception (maybe special casing autoboxing and string
>>> concatenation), and ignoring that possibility would be rather dangerous
>>> (especially for the DA case).
>>>
>>
>> Actually this is not a problem. The worst that can happen is you end up
>> initializing the variable twice at runtime (once legitimately in the try
>> block, and once again in the catch block due to the unexpected exception).
>> This is not a problem - the JVM doesn't care.
>>
>
> I think this is the worst thing that can happen:
>
> ```
> int x;
> try {
>   f1(); // no checked exception declared
>   x = 1;
>   f2(); // may throw MyCheckedException
> } catch (MyCheckedException e) {
>   System.out.println(x);
> }
> ```
> According to your rules `x` is DA in the catch, and if `f1` misbehaves and
> throws a `MyCheckedException` then you are reading an uninitialized
> variable.
>

Oh right - this reverse of my example could also happen. So in summary, you
could initialize the variable zero, once, or two times.

I still say it's not a big enough problem to worry about. If you're "going
around" the JLS with tricks, some JLS guarantees are invalidated, just like
with unchecked casts, etc.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240714/44de4f55/attachment.htm>