Does function throw? Ability to tell if a function could throw by looking at its signature.

[BlackAsLight]

🔍 Search Terms

Throw
Function signature

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When looking at functions in typescript. We can see what arguments it takes and their types as well as the type it will return. But what we don't know is if anywhere down the line of this function is if it uses the throw keyword. If it does and we don't know about it then this can very much change the behaviour of our resumed predictable code.

My suggestion is that when looking at the function signature, it indicates in some method where it could throw or not. This flag would bubble up to any function that uses the function that could throw unless wrapped inside a try catch block.

This should also apply to functions like fetch, which doesn't actually have the throw keyword in it, but can still throw.

📃 Motivating Example

This feature can help developers know and plan where and when to wrap stuff in try catch blocks to catch this undefined behaviour that somewhere further down the code breaks for an unexpected reason. The throw keyword is not a mistake of JavaScript. It is a feature and we should have better features to know when it has been used.

💻 Use Cases

1. What do you want to use this for?
   To know if a function may break and stop it from breaking the rest of my code, without adding unnecessary try catch blocks.
2. What shortcomings exist with current approaches?
   We currently have no way to know if a function may throw, with the exception of documentation or looking at source code.
3. What workarounds are you using in the meantime?
   Assuming these are fine until they break with a new unknown error.

[MartinJohns]

Duplicate of #23060 / #13219 and others.

What workarounds are you using in the meantime?
Assuming these are fine until they break with a new unknown error.

Another "workaround" is to use Railway Oriented Programming.