TypeScript 2.5: Optional catch Binding
TypeScript 2.5 implemented the optional catch binding proposal, which changes the ECMAScript grammar to allow for the omission of the variable binding within a catch clause. That is, you can now omit the error variable and its surrounding parentheses in a try/catch statement:
try {
// ...
} catch {
// ...
}
Previously, you'd have to always declare the variable even if you weren't using it:
try {
// ...
} catch (error) {
// ...
}
The Emitted JavaScript Code
If you target an ECMAScript version that doesn't support optional catch binding (such as ES5 or ES2015), the TypeScript compiler will add a variable binding to each catch clause that doesn't have one so that the generated code ends up being syntactically valid.
Here's our try/catch statement from before again:
try {
// ...
} catch {
// ...
}
And here's the JavaScript code that the TypeScript compiler emits when we target ES5:
try {
// ...
}
catch (_a) {
// ...
}
If we were to compile our code with --target esnext instead, a catch clause without a variable binding would be emitted unchanged:
try {
// ...
}
catch {
// ...
}
The Official ECMAScript Proposal
At the time of writing in late January 2018, the official ECMAScript proposal is at stage 3 of the TC39 process. Since optional catch binding isn't part of the final feature set of ECMAScript 2018, it's highly likely to be standardized as part of ECMAScript 2019.
The good news is that thanks to TypeScript, we can use optional catch binding today without having to wait for all relevant JavaScript engines to catch up with the implementation.
Use Cases for Optional catch Binding
You usually don't want to silently ignore errors in your applications. At least, you'll typically want to log them to the console. However, in some rare situations, you might not need the variable binding after all.
Let's say you're trying to log an error to the console and then, for some reason, the logging code itself causes another error. You don't want your logging code to throw an error, so in that case, a catch clause without a binding might make sense:
function log(error) {
try {
console.error(error);
} catch {
// There's not much more we can do
}
}
I encourage you to read Axel Rauschmayer's blog post about optional catch binding for a more comprehensive list of practical use cases.
This post is part of the TypeScript Evolution series:
- TypeScript 2.0: Non-Nullable Types
- TypeScript 2.0: Control Flow Based Type Analysis
- TypeScript 2.0: Acquiring Type Declaration Files
- TypeScript 2.0: Read-Only Properties
- TypeScript 2.0: Tagged Union Types
- TypeScript 2.0: More Literal Types
- TypeScript 2.0: The never Type
- TypeScript 2.0: Built-In Type Declarations
- TypeScript 2.1: async/await for ES3/ES5
- TypeScript 2.1: External Helpers Library
- TypeScript 2.1: Object Rest and Spread
- TypeScript 2.1: keyof and Lookup Types
- TypeScript 2.1: Mapped Types
- TypeScript 2.1: Improved Inference for Literal Types
- TypeScript 2.1: Literal Type Widening
- TypeScript 2.1: Untyped Imports
- TypeScript 2.2: The object Type
- TypeScript 2.2: Dotted Properties and String Index Signatures
- TypeScript 2.2: Null-Checking for Expression Operands
- TypeScript 2.2: Mixin Classes
- TypeScript 2.3: Generic Parameter Defaults
- TypeScript 2.3: The --strict Compiler Option
- TypeScript 2.3: Type-Checking JavaScript Files with --checkJs
- TypeScript 2.3: Downlevel Iteration for ES3/ES5
- TypeScript 2.4: String Enums
- TypeScript 2.4: Weak Type Detection
- TypeScript 2.4: Spelling Correction
- TypeScript 2.4: Dynamic import() Expressions
- TypeScript 2.5: Optional catch Binding
- TypeScript 2.6: JSX Fragment Syntax
- TypeScript 2.7: Numeric Separators
- TypeScript 2.7: Strict Property Initialization
- TypeScript 2.8: Per-File JSX Factories