Almost everyone who uses JavaScript daily knows that try-catch can be painful to deal with, especially when you have more than one error to handle.
Most proposed solutions are tryng to copy Golang's approach - which handles everything as return values. It is, among other things, is a great feature of Go, but JS is completely different language (duh) and I think we can do better than a copy-paste from Go.
In Go, when we want to handle an error, we return it from the function call either as a second value in tuple or as return value of the function call. Following is the pattern:
result, error := DoSomething()
if error != nil {
// handle error
}
This approach allows to handle the errors explicitly using standard control flow.
To apply this pattern in javascript the most common solution is to return results as an array:
const handler = async (promise) => {
try {
const result = await promise()
return [result, null];
} catch(error) {
return [null, error];
}
}
const [response, error] = await handle(fetch('http://go.gl'))
if (error !== null) {
// handle error
}
As you can see this is almost direct copy-paste of the pattern from Go.
Returning consistent value
This pattern works great, but in javascript we can do better than this. The core idea of this pattern is to return error as a value, so let's adapt it with better SoC.
Instead of returning null or Error we can decorate the result with a consistent interface. That would improve our SoC, and give us a strongly typed return value:
interface Status {
Ok(): boolean;
Fail(): boolean;
Of(cls: any): boolean;
}
The interface Status
doesn't have to be an Error, but we can check it's type using status.Of(Error)
. We can always return an object that sattisfies Status
. The usage example would be:
const [response, error] = await handle(res.json())
if (error.Of(SyntaxError)) {
// handle error
console.log("not a json")
return
}
Now, in JavaScript our result doesn't always have to be a tuple. We can actually create our own class that behaves as a tuple when it's needed:
interface IResult<T> {
0: T;
1: Status;
value: T;
status: Status;
Of(cls: any): boolean;
Ok(): boolean;
Fail(): boolean;
}
Usage example:
const result = await handle(res.value.json())
if (result.Of(SyntaxError)) {
// handle error
console.log("not a json")
return
}
The Implementation
Following this approach I've created ready to use function - Grip.
Grip is strongly typed and can decorate functions and promisises alike.
I use git to host such packages, so to install use github:
bun add github:nesterow/grip # or pnpm
Usage:
The grip
function accepts a function or a promise and returns a result with return value and status.
The result can be hadled as either an object or a tuple.
import { grip } from '@nesterow/grip';
Handle result as an object:
The result can be handled as an object: {value, status, Ok(), Fail(), Of(type)}
const res = await grip(
fetch('https://api.example.com')
);
if (res.Fail()) {
// handle error
return;
}
const json = await grip(
res.value.json()
);
if (json.Of(SyntaxError)) {
// handle parse error
return;
}
Handle result as a tuple:
The result can also be received as a tuple if you want to handle errors in Go'ish style:
const [res, fetchStatus] = await grip(
fetch('https://api.example.com')
);
if (fetchStatus.Fail()) {
// handle error
return;
}
const [json, parseStatus] = await grip(
res.json()
);
if (parseStatus.Of(SyntaxError)) {
// handle parse error
return;
}
Handle functions:
Grip can also handle functions:
const [result, status] = grip(() => "ok");
// result = "ok"
const [result1, status1] = grip(() => {
if (1) throw new Error("error")
});
// result1 = null
// status.Of(Error) = true
Handle generators
Generators can be handled using the Iter()
method:
const res = grip(async function* () {
for (let i = 0; i < 3; i++) {
if (i == 2) throw new Error("2");
yield i;
}
});
for await (let [value, status] of res.Iter()) {
if (status.Of(Error)) {
// handle error properly
break;
}
// typeof value === "number"
console.log(value)
}
If you like this take on error handling check out the repository. The source is about 50LOC, without types, and a 100 with types.
Top comments (1)
cool. I've been seeing alot of people implementing this style of error handling lately. I recently went the other way of producing errors as values using the Rust style enums in typescript. I think you'd probably enjoy the article I wrote this morning on the matter. Looks like we had the same thing on our minds this morning in any case... good read.