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
  • For a long time, I have been thinking about how to increase brand presence, as well as users for the blog. After much contemplation, it seems the only way is to share on social media or hope they seek it out, until...

    Wearing this shirt means no more worries about traffic jams, the more crowded it gets, the more fun it is because hundreds of eyes are watching 🤓

    (It really works, you know 🤭)

    » Read more
  • A cycle of developing many projects is quite interesting. Summarized in 3 steps: See something complex -> Simplify it -> Add features until it becomes complex again... -> Back to a new loop.

    Why is that? Let me give you 2 examples to illustrate.

    Markdown was created with the aim of producing a plain text format that is "easy to write, easy to read, and easy to convert into something like HTML." At that time, no one had the patience to sit and write while also adding formatting for how the text displayed on the web. Yet now, people are "stuffing" or creating variations based on markdown to add so many new formats that… they can’t even remember all the syntax.

    React is also an example. Since the time of PHP, there has been a desire to create something that clearly separates the user interface from the core logic processing of applications into two distinct parts for better readability and writing. The result is that UI/UX libraries have developed very robustly, providing excellent user interaction, while the application logic resides on a separate server. The duo of Front-end and Back-end emerged from this, with the indispensable REST API waiter. Yet now, React doesn’t look much different from PHP, leading to Vue, Svelte... all converging back to a single point.

    However, the loop is not bad; on the contrary, this loop is more about evolution than "regression." Sometimes, it creates something good from something old, and people rely on that goodness to continue the loop. In other words, it’s about distilling the essence little by little 😁

    » Read more
  • Alongside the official projects, I occasionally see "side" projects aimed at optimizing or improving the language in some aspects. For example, nature-lang/nature is a project focused on enhancing Go, introducing some changes to make using Go more user-friendly.

    Looking back, it resembles JavaScript quite a bit 😆

    » 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...