<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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?<br></div><div><br></div><div>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?</div><div><br></div><div><span style="font-family:monospace">    obj.method();   // might call kotlin and throw IOException??<br></span></div><div><span style="font-family:monospace">    try {</span></div><div><span style="font-family:monospace">        in.read();</span></div><div><span style="font-family:monospace">    } catch (IOException e) {</span></div><div><span style="font-family:monospace">        // handle exception<br></span></div><div><span style="font-family:monospace">    }</span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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):</div><div><br></div><div>```</div><div>try {<br>  obj.method(); // might call kotlin and throw IOException??<br>  in.read();<br>} catch (IOException e) {<br>  // handle exception<br>}<br></div><div>```</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div></div></div>