Read on Twitter
In TypeScript, I lately find myself sometimes making an "unconventional" choice about how to propagate errors: polymorphic return type of "Error | Value" — ie. function returns (but doesn& #39;t throw) an error on failure, or a value on success.
Why do this instead of just throwing? Well, the difference is at the call site; ie:
const result = fn();
if (result instanceof Error) {
return null; // or re-throw, throw new, something else
}
// Happy path continues here...
const result = fn();
if (result instanceof Error) {
return null; // or re-throw, throw new, something else
}
// Happy path continues here...
Compared with:
try {
const result = fn();
// Happy path continues here...
// ...
} catch (error) {
return null; // or re-throw, throw new, something else etc
}
try {
const result = fn();
// Happy path continues here...
// ...
} catch (error) {
return null; // or re-throw, throw new, something else etc
}
The trade-offs:
- If you need to use `finally` (eg. to do resource clean-up), you have no choice but to use `try`/`catch`.
- The `try` version forces you to indent more code.
- The `throw`-ing version is obviously better if you want to throw over several stack frames.
- If you need to use `finally` (eg. to do resource clean-up), you have no choice but to use `try`/`catch`.
- The `try` version forces you to indent more code.
- The `throw`-ing version is obviously better if you want to throw over several stack frames.
I& #39;m not sure whether there is a wrong and a right here, but I found it interesting how the safety and sophistication of TypeScript& #39;s type system has lead me to feel comfortable (almost) ignoring my long-term allergy to polymorphic return types.
And writing code in a style reminiscent of Go& #39;s (notorious) explicit error handling style. Weird, huh?
