Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Flow Analysis] throw statements in nested function calls #32602

Closed
5 tasks done
buschtoens opened this issue Jul 29, 2019 · 3 comments
Closed
5 tasks done

[Flow Analysis] throw statements in nested function calls #32602

buschtoens opened this issue Jul 29, 2019 · 3 comments
Labels
Duplicate An existing issue was already created

Comments

@buschtoens
Copy link

Search Terms

flow analysis throw error exception undefined non-null assertion optional nested function call

Suggestion

Teach flow analysis to understand throw statements in nested function calls.

Use Cases

Many frameworks, even Node's standard library, come with a range of assertion helpers. In its most basic form, they take a condition, and an error message that will be thrown, when the condition evaluates to a false / falsy value.

TypeScript currently does not understand throw statements in nested function calls, which makes using assert helpers annoying, since you have either have to repeat the same conditional throw statement right after the assertion, use a non-null assertion, or a type cast, to tell TypeScript, that this value is present / fulfills some further criteria.

Examples

function assert(message: string, condition: boolean) {
    if (!condition) throw new Error(message);
}

function foo<T>(someArg?: T): T {
    assert('Argument missing.', Boolean(someArg));

    // Toggle this line to fix:
    // if (!someArg) throw new Error('Argument missing.');
    
    return someArg;
}

TypeScript REPL

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

Possible Duplicates / Related

@MartinJohns
Copy link
Contributor

Duplicate of #32130, #10421, #31512, #31879, #17760.

@yortus
Copy link
Contributor

yortus commented Jul 29, 2019

Sounds like #8655

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Jul 29, 2019
@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

5 participants