Try/Catch DU Exception

[Olexandr Rotan]

I would sise with Atilla here, at least partially. While it's perfectly
reasonable to focus on J in JDK, jdk is still a widely used platform for
many languages, that are built on top of trust into respect of JVM-based
languages by Java designers.

Specifically in that case, I wouldn't say that this is kind of an issue
that is significant enough to discard the idea, it is still a con of this
change, and, imo, must be accounted. Though for kotlin specifically, there
are much greater compromises that kotlin devs are used to than final
variable that may be accidentally initialized twice

On Mon, Jul 15, 2024, 21:30 Archie Cobbs <archie.cobbs at gmail.com> wrote:

> 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/fbda77b1/attachment.htm>