EDITING RESPONSE BASED UPON QUESTIONS FROM OP
This is really in response to the comment:
All you have done is written up a clear-cut example of a straw man argument: you are vicariously introducing the tacit assumption that there must always be one and only one default value, valid for all call sites
I believe that we are approaching the entire question from opposite ends. It seems that you are looking at it from the bottom up - literally from the bytecode and going up to the Java. If this is not true, you are looking at it from the "code" compliance to the spec.
Approaching this from the opposite direction, from the "design" down, I see problems. I think it was M. Fowler who collected various "bad smells" into the book: "Refactoring: Improving the Design of Existing Code". Here (and probably many, many other places) the "Extract Method" refactoring is described.
Thus, if I imagine a made-up version of your code without the 'calculateIndex' method, I might have something like this:
public void someMethod() {
final int i;
try {
int intermediateVal = 35;
intermediateVal += 56;
i = intermediateVal*3;
} catch (Exception e) {
// would like to be able to set i = 1 here;
}
}
Now, the above COULD have been refactored as originally posted with a 'calculateIndex' method. However, if the 'Extract Method' Refactoring defined by Fowler is completely applied, then one gets this [note: dropping the 'e' is intentional to differentiate from your method.]
public void someMethod() {
final int i = calculateIndx();
}
private int calculateIndx() {
try {
int intermediateVal = 35;
intermediateVal += 56;
return intermediateVal*3;
} catch (Exception e) {
return 1; // or other default values or other way of setting
}
}
So from the 'design' perspective the problem is the code you have. Your 'calculateIndex' method does NOT calculate the index. It only does sometimes. The rest of the time, the exception handler does the calculation.
Furthermore, this refactoring is far more accommodating to changes. For instance, if you have to change what I assumed was the default value of '1' to a '2', no big deal. However, as pointed out by the OP reply quoted, one cannot assume that there is only one default value. If the logic to set this grows to be only slightly complex it could still easily reside in the encapsulated exception handler. However, at some point, it too may need to be refactored into it's own method. Both cases still allow the encapsulated method to perform it's function and truly calculate the index.
In summary, when I get here and look at what I believe is the correct code, then there is no compiler issue for discussion. (I am most certain you will not agree: that is fine, I just want to be clearer about my viewpoint.) As for compiler warnings that come up for incorrect code, those help me realize in the first place that something is wrong. In this case, that refactoring is needed.