he/him 
My short TypeScript wish list: - Only allowing `Error` instances to be thrown - Enforcing that interpolated values in template literals are strings
Show this thread
I run into `throw undefined;` surprisingly often and it is so so difficult to debug (doing it right now). It's one of the most easiest things a type system could detect.
-
-
@typescript's scope is compilation to JS and not linting. I wish that wasn't the case and tsconfig.json could support severity levels per rule and rules like you suggest. At the moment however we have to rely on userland tooling for such cases, so@geteslint . -
TypeScript already restricts JS semantics. This is as much linting as any other type restriction.
- 1 more reply
New conversation -
-
-
I don’t know if this is helpful for your use cases, but it inspired me to do thishttps://github.com/nodejs/node/pull/30025 …
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
you could make a babel plugin to make `throw not-error;` a runtime error
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I wonder if they could add a type definition for thrown exceptions eg "throws Error | string" which defaults to any or unknown
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
throw Error;
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
The compiler or linter could easily check every explicit use of `throw` but sadly we would still not be able to make assumptions about the type in `catch` since errors can be thrown from dependencies. I wonder if there’s a JS proposal to wrap non-errors…
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.