Comment 1 Markus Keller 2010-01-26 05:35:11 EST

(This bug is a follow-up to bug 285000 comment 6.)

I actually made it deliberately like this. Quick fixes are supposed to be local, and it's OK if they leave code with compile errors after they applied the local fix.

E.g. in this example, we also don't add a throws declaration or a catch block if you add a 'throw' to the IOException:

    public void foo(int i) {
        if (i == 1) {
            new IOException();
        } else if (i ==2) {
            return;
        }
        new String("Unused allocation");
     }

If we start fixing follow-up problem automatically, this becomes unpredictable (e.g. if the method already returns an 'int', should that also be changed to 'String', ...). The user should see that there's still a problem in the code, and she can easily fix the follow-up problem with another quick fix if that makes sense.

Comment 2 Dani Megert 2010-01-26 05:43:51 EST

Why not do the right thing and add the return type?

Comment 3 Markus Keller 2010-01-26 06:49:22 EST

> Why not do the right thing and add the return type?

Because
- it would be an unannounced side-effect
- we don't know what's the right return type. It could be any supertype. The user should become aware of the problem, and if necessary apply the second quick fix and explicitly choose the return type from the popup.