Try/Catch DU Exception

Archie Cobbs archie.cobbs at gmail.com
Mon Jul 15 18:29:37 UTC 2024


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

> 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.
>>
>
> The reason I would worry is because there are languages like Kotlin and
> from its own perspective it is perfectly fine to throw any exception. And
> someone might want to call it from Java (not realizing the possibility). I
> think this is worse than unchecked casts and whatnot, because it doesn't
> blow up in your face. You will just get an impossible value (likely 0 or
> similar) which would be very hard to track down if it happens. Given that
> you are catching the exception, you might not even get to see the
> stacktrace in the logs. I think this would only be an acceptable risk if
> the compiler would protect you from such exceptions by wrapping the checked
> exception into an unchecked one.
>

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
    }

-Archie

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


More information about the amber-dev mailing list