Type widened prematurely in catch

[haines]

🔎 Search Terms

"type widening", "try-catch"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about try-catch

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.5.0-dev.20240328#code/IYZwngdgxgBAZgV2gFwJYHsIwCboO4QA26w2AFCOggE5QCmAXDCMtahAOYwA+MASnRAAHTCDoBKJgAVq6ALaoxAHhZtOAPhgBvAFAwYqODDLIwQuuiOUa9GAF4HMAESr2HJ+O179MVmC8+Pta0dPYwwHjAqMjwdMhQABYUVCHiANze+gC+MFDA8QnGdNSy1J66gfrB9BkA9LWBAHoA-Jk+yAmyeDDFpRmBWd6D3tRxNFgRUTHVdAB0yHQAHshk6TpZQA

💻 Code

async function download(source: string | Response): Promise<string> {
  if (typeof source === "string") {
    try {
      source = await fetch(source);
    } catch (error) {
      source;
//    ^? (parameter) source: string | Response
      throw error;
    }
  }

  return await source.text();
}

🙁 Actual behavior

When reassigning a variable inside a try block, the type of the variable is widened inside the catch block even if the assignment cannot have taken place if an error was thrown. In this example the source can only be a string inside the catch block, but the compiler is treating it as string | Response.

🙂 Expected behavior

The type of the variable is only widened if the assignment could have taken place before the error was thrown.

Additional information about the issue

No response

[RyanCavanaugh]

We don't do any analysis of what operations "could"/"could not" have generated exceptions, including the special case of zero operations, since this comes up fairly rarely, is expensive, and would cause some "Well it works if I hold it this way but not this way" confusion where people assume that operations which actually can throw (property access, etc) cannot.

[haines]

Fair enough!