Assignments in the try-block are unconditionally assumed to have never happened in the catch-block

[kujon]

TypeScript Version: 2.4.0

Code

The following is self-explanatory and nice. There is only one way an error can be thrown, therefore the compiler can make an assumption that res never got assigned in the try-block, if the catch-block is reached.

const throwing = () => { throw new Error(); };

let res = null;

try {
    res = throwing();
} catch (ex) {
    if (res) {
        // Property 'value' does not exist on type 'never'.
        console.log(res.value);
    }
}

If we start adding to this example however, strange things happen. In the example below, the compiler makes the same assumption, even though it seems incorrect. res1 assignment succeeded and its value will be { value: 42 } in the catch-block.

const nonThrowing = () => ({ value: 42 });
const throwing = () => { throw new Error(); };

let res1 = null;
let res2 = null;

try {
    res1 = nonThrowing();
    res2 = throwing();
} catch (ex) {
    if (res1) {
        // Property 'value' does not exist on type 'never'.
        console.log(res1.value);
    }
    if (res2) {
        // Property 'value' does not exist on type 'never'.
        console.log(res2.value);
    }
}

Expected behavior:
I'm not necessarily sure how this could be solved tbh. The only naive thing that comes to my mind is to only make this assumption about the last assignment in the try-block.

[kujon]

Any updates on this?

[DanielRosenwasser]

I think the real problem is that you can't even fall back to a declared type as so:

interface SomeOtherType { }
let res: SomeOtherType | null = null;

try {
    res = null! as SomeOtherType;
}
catch (x) {
    if (res) {
        res // has type 'never'
    }
}

[RyanCavanaugh]

We don't have any mechanisms right now for retrieving all possible exception-sourced exit points from the control flow graph. Doesn't seem worth it to add that much machinery for just this case.