This rule raises an issue when built-in Error constructors are called without a message parameter or with an empty string message.
Error messages are crucial for debugging and maintaining JavaScript applications. When you create an Error object without a message, you lose valuable information about what went wrong and where.
Built-in Error objects like Error, TypeError, RangeError, and others are designed to carry descriptive
messages that help developers understand the cause of an issue. Without these messages, debugging becomes much harder, especially in production
environments where stack traces might be the only clue about what happened.
Empty error messages are just as problematic as missing ones. They provide no context about the error condition and force developers to rely solely on stack traces and surrounding code to understand the issue.
Meaningful error messages serve multiple purposes:
Without meaningful error messages, debugging becomes significantly more difficult and time-consuming. Developers may struggle to identify the root cause of issues, leading to longer resolution times and potentially overlooking important problems. In production environments, unclear errors can make it harder to monitor application health and respond to incidents effectively.
Provide a descriptive message when creating Error objects. The message should clearly explain what went wrong or what condition was not met.
throw new Error(); // Noncompliant
throw new Error(''); // Noncompliant
throw new TypeError(); // Noncompliant
throw new Error('Unexpected property found');
throw new Error('Invalid configuration provided');
throw new TypeError('Expected array but received string');