You've made 3 changes here. The first line seems sensible and is covered by a test case, but the other two are less clear. Could you elaborate on those choices and add some tests for them? In particular, why is the branch not important for throw and return statements?

During the evaluation I saw a lot of FP that matched the following pattern:

if (!taintedCondition) {
    throw new Exception();
    // or
    return errorCode;
}

doLogin();
doOtherSensitiveStuff();

Before the change, the query was assuming that the if block was a way of bypassing the authentication, but actually it interrupts the execution flow with an error and nothing sensitive is executed.

Of course this approach has tradeoffs (since the heuristic nature of the query makes it hard to be 100% precise), in which a block containing a return or throw statement does something sensitive first, but it seemed that the FP reduction was worth a limited FN increase. Happy to discuss it further, though.

In any case, I wanted to add tests for this but I forgot, I'll do it now.

So for this example it seems like you want
not cb.controls(any(ThrowStmt t).getBasicBlock(), cond.booleanNot())
in order to say that the throw statement is in the other branch, right?
I'm a little less convinced by the return statement, but if it really does help to filter FPs then I guess it should also specify the branch to be cond.booleanNot(), right?

Good catch! By adding this, a MISSING test case gets fixed, so thank you :) See 21079a1.

Regarding the return statement, I can run one evaluation with the query as-is and one without the exception for return statements to see what's its real impact on FP, if you think it makes sense.

Yeah, if it should be there it should probably be not cb.controls(any(ReturnStmt r).getBasicBlock(), cond.booleanNot()), but an evaluation to check its impact is probably good.

I ran this, and when the return exception is not applied, the results go up from 155 to 365 projects. After a cursory review, most of those 210 extra projects' results seem to be FPs.

Thanks for checking. Makes sense to keep it then.