Beside Error Handling, Creating Errors with Error Objects Is Equally Important

Beside Error Handling, Creating Errors with Error Objects Is Equally Important

Daily short news for you
  • Now everything is so modern that people can come up with anything. ferretdb.com is an open-source project that transforms the PostgreSQL database into... MongoDB. That's right, you heard it correctly. If you still want to use Postgres but prefer the Mongo query syntax, then ferretdb is for you.

    Oh, besides PostgreSQL, it can also connect to SQLite. Awesome!!! 🙏

    » Read more
  • Dedicating this to those of you using Cursor. PatrickJS/awesome-cursorrules gathers some .cursorrules files to optimize prompts for Cursor. Imagine these files as the System Prompt for Cursor, controlling it according to your wishes in each project.

    The usage is really simple, just copy the appropriate .cursorrules file and place it in the root folder of the project 🥳

    » Read more
  • Gemini 2.5 has just been released, everyone. This is the most advanced model from Google to date, with top-notch reasoning and coding capabilities - as they introduce it.

    Everyone, take a look at the benchmark table; the metrics are all superior to the other competitors. We don't know the price yet, but you can try it for free in Google AI Studio. I guess we’ll wait for it to be integrated into Cursor to see how its coding abilities measure up 😁

    » Read more

The Issue

A while ago, I wrote an article on Error Handling Techniques in Node.js, focusing on how to catch errors and handle them effortlessly. In this article, we'll temporarily set aside those techniques and dive deep into the topic of "throwing" errors and how to "catch" them effectively.

I believe many of us, including myself, have thrown an error that looks like this:

function login(username, password) {
  // code
  if (password != hash_password) {
    throw new Error("Password is incorrect");
  }
// code
}

Then we "catch" the error:

try {
  login("admin", "123456");
} catch(e) {
  console.log(e.message);
  // logic handle
}

There's not much to discuss about error handling in the code above. When you "throw" an Error, it carries a lot of useful information causing the error, such as the stack trace and error message. Therefore, e in catch(e) helps us easily trace the origin of the error for proper handling.

I've encountered cases where errors were thrown incorrectly, instead of using new Error, a string or an object was thrown. Something like:

throw 'Password is incorrect';

With this approach, we can still use try catch. However, e in this case is simply a string or an object that you threw earlier, lacking important information like stack trace and message as in Error. That's why, whenever you throw an error, it should be turned into an instance of Error.

Error accepts a string parameter, which is also the content of e.message. If you deliberately pass more than one parameter or a parameter that is not a string like an object, it will result in something like this:

throw new Error({ "name": "2coffee" });

VM400:1 Uncaught Error: [object Object]
    at <anonymous>:1:7

I bring up this issue because there are many cases where we need to include additional information in an error for convenient handling of certain logic. For example, besides message, I may need to add uuid as the ID of the record causing the error, detail containing a more detailed description, code to specify the error code defined in the system... and that's impossible with Error.

Is there a way to achieve this?

Errors Class

Error is an object thrown when a runtime error occurs. It can also be used as a base object for errors defined by users. In simpler terms, you can create a class that inherits from Error to create your own error object.

JavaScript provides some "custom" error objects based on Error that you might have encountered many times, such as:

To see a full list of error types, you can refer to Error types - Mozilla.

The commonality among them is that they are based on Error, so they have all the important attributes of Error. Additionally, these errors bring transparency to your code. For example, when throwing a RangeError, we can know that the error is caused by a value that is outside the allowed range, instead of a generic throw new Error('The argument must be between 1 and 10').

To differentiate error objects, you can simply use conditional statements like if...else, switch...case...

if (err instanceof RangeError) {
  // handle RangeError
} else if (err instanceof ReferenceError) {
  // handle TypeError
}
...

These custom error objects are similar to Error, with the only difference being their name. So, if you need a more "distinct" error, let's move on to the next section.

Custom Errors Class

We can define our own types of errors by inheriting from Error. Then, throw an error with throw MyError and use instanceof MyError to check the error type in catch. This leads to cleaner and more consistent error handling code.

The simplest syntax to create a custom MyError:

class MyError extends Error {
  constructor(message) {
    super(message);
    this.name = this.constructor.name;
  }
}

MyError is now assigned the name of constructor.name, which is also the name of the MyError class. However, it doesn't have much difference compared to a regular Error, except for the name. We need to add a few properties like code for error code and statusCode to define HTTP response status codes.

class MyError extends Error {
  code;
  statusCode;

  constructor(message, code, statusCode) {
    super(message);
    this.name = this.constructor.name;
    this.code = code;
    this.statusCode = statusCode;
  }
}

To throw an error, use the syntax throw MyError:

try {
  throw new MyError("My error message", 123, 404);
} catch (err) {
  console.log(err.name, err.message, err.code, err.statusCode);
  // MyError My error message 123 404
}

With this feature, you can create many custom errors for your specific handling purposes. For example, create ApplicationError, DatabaseError, ValidationError, etc., with similar features to system errors, database errors, data validation errors... to hide or display error messages to users.

Conclusion

Error is an object for handling errors in JavaScript programs. The best way to throw an error is to throw an Error instead of a string or another object. JavaScript defines some "custom" error types based on Error, such as ReferenceError, SyntaxError, RangeError... In addition, you can create custom error types by inheriting from Error.

References:

Premium
Hello

The secret stack of Blog

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

View all

Subscribe to receive new article notifications

or
* The summary newsletter is sent every 1-2 weeks, cancel anytime.

Comments (0)

Leave a comment...