Community
Participate
Working Groups
I occasionally find myself creating a try-catch containing a variable declaration that I later find I need outside of the block. I have to cut/paste the declaration to above the try-catch (assigned null) and then remove the type from the variable inside the try-catch. A refactoring to do this automatically would be very handy. For example: try { SomeClass x = ... } catch (Exception ex) { ... } would become SomeClass x = null; try { x = ... } catch (Exception ex) { ... } after the refactoring.
Move to JDT/UI
Looks like a good idea for a quick assist (a new refactoring is a bit heavy weight for that)
(In reply to comment #2) > Looks like a good idea for a quick assist (a new refactoring is a bit heavy > weight for that) > A Quick Assist would be fine.
'Split declaration' quick assist plus 'Alt+Up' can be used to do this (see bug 102816). But then it still leaves initialization to null. I think the compiler will eventually complain in most cases after splitting the declaration - 'variable may not have been initialized'. Hence I wonder if 'Split declaration' should also initialize to null...
> I think the compiler will eventually complain in most cases after splitting the > declaration - 'variable may not have been initialized'. Hence I wonder if > 'Split declaration' should also initialize to null... It's actually a good thing that the compiler complains in these cases. The user should be forced to think about the right way to fix this problem. Initializing to null is just one option -- but not necessarily the right one. Example: public void foo() { FileInputStream fileInputStream; try { fileInputStream= new FileInputStream("a"); } catch (FileNotFoundException e) { e.printStackTrace(); } System.out.println(fileInputStream); } In this case, we already have a quick fix "Initialize variable", so we don't have to do anything for the "Split declaration" case. But besides the "Split declaration", this bug is about adding another quick assist that - splits the declaration - moves the declaration in front of the enclosing block (or even further up if there are already unresolved references to the selected variable in an outer scope) - initializes the variable with the default value and enters linked mode with the initializer selected
Having a "Quick Fix" that produces code that will not compile is a bad idea. One of the alternatives (initialize to null, etc.) should be provide automatically.
*** Bug 333226 has been marked as a duplicate of this bug. ***
*** Bug 355286 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Having a "Quick Fix" that produces code that will not compile is a bad idea. > One of the alternatives (initialize to null, etc.) should be provide > automatically. 90% of the times initializing to null works, so I will vote to initialize it to null automatically. I will also add that the cursor should remain in the original location of inline variable so that developer does not get distracted form the logic he is already working on in that line.
