<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>Yes, this definitely falls into the category of "tactical fix". It's a specific (small) fix for a specific (small) corner case.<br></div><div><br></div><div>You raise a good question re: whether we should be looking at a bigger picture, for example your if/then/else example. That would mean replacing "last statement of the block is V=x" with something more general.<br></div><div><br></div><div>My concern is that extending this idea in that way would necessarily be much more invasive to the spec. Instead of defining and tracking two things (DA and DU) for every possible expression, the JLS would now have to track three things: DA, DU, and "DU for the purpose of catch". Chapter 16 would expand by 50%.</div><div><div><br></div><div>So this changes the cost/benefit equation by a lot.</div><div><br></div></div><div>Or... maybe there's some simpler trick that would accomplish the same thing? If so I don't immediately see it.</div></div></blockquote><div><br></div><div>Maybe somewhat more invasive to the spec but I don't think it would be the place you are referring to. So, if the spec had the concept of "nothrows" (i.e., when an expression / statement cannot throw an exception), then you "just" needed to change the flow analysis. It would not need "DU for the purpose of the catch". I didn't try to formalize it but I don't see it more complicated than a break / continue of a loop. At least in this case I would be mostly neutral about the change because it would be conceptually more compact.</div><div><br></div><div>My problem with this special case is that it is rather arbitrary to just rule that this is important and others are not, and if things get "fixed" on a case by case basis, then I worry that the language rule will effectively evolve into: "Let's type it in, and see if the compiler is ok with it". Which pretty much the case for generic type inference, and that doesn't have a good track record for being bug free. In fact, I remember reporting one bug in it on the javac list, and the response I got was basically that "we are aware but it is too complicated to fix" (and I can empathize with that). I would avoid going down the route of special rules for something like this. Especially since it is actually rare (though annoying of course), and the workaround is mostly trivial (you can factor that out into a method).</div><div> </div><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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Especially because then it raises
 more questions about `Thread.stop`.</blockquote><div><br></div><div>Like what? In the source code, the catch block still can't <i>use</i> the variable, because it's still not DA. All that's changed is that it can now <i>assign</i> the variable.</div></div></div></blockquote><div><br></div><div>I guess given Tagir's comment that `Thread.stop` is not a thing now, it is a non-issue. But if it still worked, then the question you would be asking is: "Can an exception be raised after the last statement but before the end of the `try` block?". To be honest I was never sure if that was possible or not, and I hated to think about the possibility of `Thread.stop` until I just accepted that I won't because it is practically impossible to write a code that is guaranteed to remain consistent after an asynchronous exception.</div><div> </div><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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Where this is annoying is when you want to capture the variable (mostly 
in a lambda). However, if that is the issue that you are trying to 
address, then I think this is the wrong solution to that issue. I think 
the real solution to the issue would be relaxing the constraint to be 
able to capture a local variable: We should be able to capture it, iff 
the variable is definitely assigned before capturing, and there is 
definitely no assignment after it.</blockquote><div><br></div><div>That's <i>not</i> the issue I'm trying to address, but I totally agree with you that it would also be a good one to have. Are you officially proposing it? If so, I support you :)</div></div></div></blockquote><div><br></div><div>I'm not sure what counts as official but I would much certainly welcome such a change. I have always found it silly that you can't capture a local variable just because it took multiple steps to initialize.</div></div></div>