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