Open octogonz opened 3 years ago
YES, PLEASE. And ideally also a rule to bring back the TypeScript 3.x behaviour with Error being default type for catch block errors, so we don't have to specify Error type in every try-catch block
right now I'm forced to annotate all caught errors as "any" which ruins intellisense.
Yes! I think that would be a good trade-off for situations where we can be sure to receive an "Error" object!
Duplicate of https://github.com/microsoft/TypeScript/issues/20024
@ExE-Boss There is a slight difference between the two issues: #20024 is asking for arbitrary type annotations for catch blocks, whereas #42596 is /only/ asking for catch (e: Error)
only.
The rationale given above was:
Error
interface. We have lint rules that enforce this. And external packages generally follow this rule as well, at least the kind we'd use for professional work.catch
block to perform paranoid runtime tests for instanceof Error
.instanceof Error
for transpiled code.unknown
they can enable it via a lint rule like no-implicit-any-catch without any involvement from the compiler.These points apply to Error
because that interface describes the bare minimum properties that any sane error object should have. Whereas these points maybe would NOT be convincing for custom error interfaces.
That said it does look like @DanielRosenwasser suggested the same idea in https://github.com/microsoft/TypeScript/issues/20024#issuecomment-344511199:
I do like the idea of
catch (err as Error)
because, damn it, if you were going to cast it anyway, maybe we should make your life a little easier while keeping it explicit.
I think that catch (e as Error)
is preferable to catch (e: Error)
. The latter looks like it's something the type-checker would verify for us (which it's not), while the former looks exactly like the unsafe cast that it is.
The practical result of not having a syntax like this is that people just use the default any
behavior. And catch (e)
is not only less visibly a type risk than catch (e as error)
, it is also dangerously over-flexible as a typing:
messsage
, ande.stack.substr(10)
.Adding catch (e as Error)
will make code safer, easier to read, and more self-documenting.
It's worth pointing out that the TypeScript code base builds with useUnknownInCatchVariables=false
.
Maybe the priority for this problem would be more apparent if the compiler developers had to use their own feature. π
I think that
catch (e as Error)
is preferable tocatch (e: Error)
. The latter looks like it's something the type-checker would verify for us (which it's not), while the former looks exactly like the unsafe cast that it is.
@MickeyPhoenix This is a really great suggestion. I'm going to update the issue description to include your idea.
Thanks! I wish I could take credit for it, but actually it's from @jaredru's comment (here) as highlighted by @DanielRosenwasser (here). I just spelled out why I think it's such a great idea. :-)
As much as I'd like to, I can't quite support the catch (e: Error)
variant, because it is an invisible type-cast. But I sure would love the explicit-cast option!
It's worth pointing out that the TypeScript code base builds with
useUnknownInCatchVariables=false
.
Setting useUnknownInCatchVariables=false
is a pretty good workaround for this problem. π
Turns out it requires TypeScript 4.4 however (which was surprising since the problematic validation was introduced in 4.0). As soon as I added the setting to our rig, we started seeing breaks in projects that build using an older compiler. Just something to be aware of.
It would be super awesome if useUnknownInCatchVariables
could be backported to 4.0.x-4.3.x.
I tried this, without setting nothig. I don't know if it's a optimal solution. I use firebase auth.
Suggestion
TypeScript 3.x forbids type annotations in
catch
blocks:But TypeScript 4.x relaxed this rule to accept
any
orunknown
only:β Suggestion: Could we relax the rule to allow
Error
as well?Such a declaration would not accurately describe pathological JavaScript code.
But here's why it makes sense anyway:
Error
interface. We have lint rules that enforce this. And external packages generally follow this rule as well, at least the kind we'd use for professional work.catch
block to perform paranoid runtime tests forinstanceof Error
.instanceof Error
for transpiled code.unknown
they can enable it via a lint rule like no-implicit-any-catch without any involvement from the compiler.Alternate syntax
In the thread below, @MickeyPhoenix suggested to use
as
instead of:
to clarify that technically this is a type cast, while still keeping the syntax concise and intuitive:π Search Terms
catch
instanceof
TS1996
1996
β Viability Checklist
My suggestion meets these guidelines: