Error handling is part and parcel of good software development.
You could probably live without them if you’re building a landing page, an invitation card, and maybe (hopefully) an MVP?!.
However, if you ever want to delve deep into building world-class products, projects that stand the test of time, you need some good error-handling skills in your arsenal.
Last week, I published a helpful guide on try and catch block error.
Today, I’m in the mood (actually, a bug put me in the mood :)) to talk about “throwing errors”
Let’s get right in.
Throwing errors
I sincerely got to learn about throwing errors, playing with Supabase.
E.g, A typical fetch query to Supabase could look like this…
const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)
The error object provides information about errors encountered from your interactions with Supabase.
For example, think of fetching a column that doesn’t exist, or inputting the wrong column name in an insert request.
That obviously won’t work.
Supabase tries to let you know where the problem comes from, and they do it best with the error object.
So how do you handle this error object?
That’s where the concept of “throwing” comes in.
PS: If you don’t know what Supabase is, it’s basically a BAAS. It’s primarily known for its database services, similar to Firebase but built on PostgreSQL (the icing on the cake).
Exception
You genuinely can do whatever you want with an error object.
A younger me would probably console.log, but that’s bad practice.
Arguably, every error should raise an exception.
In other words, every error should gracefully stop a code from running.
E.g., instead of your app crashing for poor internet connectivity, your app should gracefully realize “Network connection failed” and do whatever you tell it to do.
This is exactly what the catch block in JavaScript’s “try and catch” does.
When the code in the try block fails, the catch block is gracefully executed.
This is broadly the definition of “exception.”
It stops a code and creates a backup plan.
So how does throw come into play?
Throw
Throw is a JavaScript keyword that raises an exception.
Remember, an exception stops the code from running and creates a backup plan.
Throw?
Throw raises an exception.
It tells an exception, “alright, this is the time you stop the code and do your backup thingy.”
Here’s a good example…
try {
const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)
throw error
} catch (err) {
}
At the point of “throw” there, the code stops.
Try and catch block
Throw raises an exception. It doesn’t handle the exception. A try and catch block does.
Let me illustrate again.
Look at this code,
try {
const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)
throw error
} catch (err) {
console.error(err)
}
Usually, the “throw” always looks for the nearest catch block to handle its value.
If the value is “error” (like in our case), it sends it to the catch block to handle it.
The catch block receives value via the prop.
catch (err) {
console.error(err)
}
At this point, you can console.log(), console.error, etc.
The industry standard, however, is to console.error so your browser recognizes it as an error
PS: Without a throw, catch would wait for the try block to fail before resorting to the catch block. With a throw, it immediately resorts to the catch block that moment, passing the value of the throw to the catch block prop.
I believe you better understand what this code does…
try {
const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)
throw error
} catch (err) {
console.error(err)
}
throw error vs throw New Error
So what’s the difference between throw New Error() and throw error?
The “new Error()” is the only difference.
throw new Error is basically a throw with a safety helmet.
throw could actually throw anything in reality.
Could be a string, number, or even an error object.
Here’s what I mean…
throw 'Something went wrong'; // throws a string
throw 404; // throws a number
throw { message: 'Bad request' }; // throws an object
Any time you throw “new Error”, it becomes the “throw new Error()” we’ve been talking about.
“new Error” is an instance of an error.
Take a deep breath.
An instance of an error, is just a fancy label that informs javascript that whatever you’re throwing is actually an “error”, so they can employ their complete arsenal of tools to combat the error.
When should use one over the other
Simply put, if a service has an error object, use…
throw error
If it doesn’t and you’re manually creating the errors labels for yourself, use…
throw new Error()
The reason is simple…
The error object from a service is most likely rich with every information you need. You most likely don't need to hamper it. Always, send the error straight to your logs.
On the other hand, when you run a service yourself or want to handle error and their type manually, use error new Error().
______
Lastly, keep in mind, throw takes any value. String. Numbers. Objects.
throw new Error() only takes strings.
Top comments (0)