reproducible

It seems that identified data flow paths do not include potential abrupt termination of try command in any place because of RuntimException.

To fix this, the IDE would have o understand that the method throwException never returns normally. Since the IDE (now) does not know, it assumes normal return from throwException which means value of `x' is reassigned again.


I would not say that it is a defect, because in all but very simple cases it's very hard to assess the method always throws - i.e. the method is public - may be overriden, it's hosted on another class - requires nonlocal analysis etc.

In order to fix that, user annotation (something like @AlwaysThrows) would be useful, as well as an index from the flow analysis, which marks methods as @AlwaysThrows when the parser/indexer discovers that case - nonlocal analysis can be reduced to a simple index check.

Correction. In this situation, an unexpected exception like OOM or LinkageError may be thrown at any time, so it does not matter if the called method itself completes normally or abruptly.

Fixed in experimental impl, wait for umbrella issue to close

(In reply to Svata Dedic from comment #3)
> To fix this, the IDE would have o understand that the method throwException
> never returns normally. Since the IDE (now) does not know, it assumes normal
> return from throwException which means value of `x' is reassigned again.
> 
> 
> I would not say that it is a defect, because in all but very simple cases
> it's very hard to assess the method always throws - i.e. the method is
> public - may be overriden, it's hosted on another class - requires nonlocal
> analysis etc.
> 
> In order to fix that, user annotation (something like @AlwaysThrows) would
> be useful, as well as an index from the flow analysis, which marks methods
> as @AlwaysThrows when the parser/indexer discovers that case - nonlocal
> analysis can be reduced to a simple index check.


It doesn't matter if the "throwException" method throws an exception always or only under certain conditions.
The method always throwing an exception was used just for simplicity. (In fact, I came across the invalid hint in a real-life project.)
In the modified sample below the invalid hint is shown as well, even when the "canThowException" method doesn't always throw an exception:

    private void test() {
        int x = 0;
        try {
            x = 1; // <= Invalid IDE hint: "The assigned value is never used"
            for (int i = 1; i <= 5; ++i) {
                canThrowException(i);
            }
            x = 2;
        } finally {
            System.out.println("x = " + x);
        }
    }
    
    private void canThrowException(int value) {
        if (value > 3)
            throw new RuntimeException();
    }

I've changed the algorithm so that before each assignment and 'in between' each method invocation (after parameters are evaluated and before return value is used) the analyzer conditionally evaluates Throwable subclasses so:
* the simulation reaches RuntimException/Error handlers, if they are present
* the simulation reaches finally clause bypassing any handlers, if Throwable is not caught

This covers your situation as well as random VM errors. The drawback is ibncreased complexity - many paths of execution, especially if the try { } catch|finally { } modifies variables outside the try block so that multiple interim states can be seen in catch/finally.