Weird behavior with inference related to nullable types

[Arnavion]

/**
 * @flow
 */

function foo() {
    var str: ?string = "5"; // Line 6
    if (str === null) {
        throw new Error("str is null");
    }

    var str2 = str;
    str2.toString();
    var str3: string = str2; // Line 13
}

/stuff/src/flow-experiments/test.js:6:15,20: undefined
This type is incompatible with
  /stuff/src/flow-experiments/test.js:13:15,20: string

/stuff/src/flow-experiments/test.js:13:15,20: string
This type is incompatible with null

Found 2 errors

Not sure if this is related to #21 but:

• It seems typechecker doesn't realize that str cannot be null after the if() that checks for === null (Does it not consider throw as exiting the function?)
• If typechecker does think that str, and thus str2, is ?string, then why doesn't it complain about the .toString() on a possibly null value?
• If typechecker does think that str, and thus str2, is string, then why does it complain that str2 is potentially null when assigning it to str3?

If I change the condition to == null, I get:

/stuff/src/flow-experiments/test.js:6:15,20: null
This type is incompatible with
  /stuff/src/flow-experiments/test.js:13:15,20: string

/stuff/src/flow-experiments/test.js:6:15,20: undefined
This type is incompatible with
  /stuff/src/flow-experiments/test.js:13:15,20: string

Found 2 errors

Only by adding an (unreachable) return after the throw and changing the condition to == null do I get no errors.

/**
 * @flow
 */

function foo() {
    var str: ?string = "5";
    if (str == null) {
        throw new Error("str is null");
        return;
    }

    var str2 = str;
    str2.toString();
    var str3: string = str2;
}

[Arnavion]

Might be a duplicate of #13

[sophiebits]

Seems more related to #21 to me, personally.

[Arnavion]

It's a mix of both, I guess. The fact that throw doesn't short-circuit the branch analyzer is your issue #13 , and the fact that === null doesn't work seems related to #21

[sophiebits]

Ahh, yes. Sorry, I missed the throw completely. Not sure what I was thinking.

[gabelevi]

We fixed the control-flow logic awhile back to understand that an uncaught throw is terminal. So the version of the code with == works with no errors now. Sorry for forgetting to close out this issue!