oxc-project/oxc · warning · OxcDiagnostic
Error message should not be an empty string.
Error message
Error message should not be an empty string.
What it means
Diagnostic from oxlint's `unicorn/error-message` rule. The message argument exists but is an empty string: either a `''`/`""` string literal or an empty template literal (span of exactly two backtick characters). An empty message gives consumers of the error no information, so the rule asks for a non-empty string describing what went wrong.
Source
Thrown at crates/oxc_linter/src/rules/unicorn/error_message.rs:21
ast::{Argument, CallExpression, Expression, NewExpression},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_semantic::IsGlobalReference;
use oxc_span::Span;
use crate::{AstNode, context::LintContext, rule::Rule, utils::BUILT_IN_ERRORS};
fn missing_message(ctor_name: &str, span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn(format!("Pass a message to the {ctor_name:1} constructor."))
.with_help(
"A descriptive message makes the error easier to debug when it is caught or logged.",
)
.with_label(span)
}
fn empty_message(span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn("Error message should not be an empty string.")
.with_help("Provide a non-empty string that describes what went wrong.")
.with_label(span)
}
fn not_string(span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn("Error message should be a string.")
.with_help(
"The first argument to an error constructor should be a string describing the error.",
)
.with_label(span)
}
#[derive(Default, Debug, Clone)]
pub struct ErrorMessage;
declare_oxc_lint!(
/// ### What it does
///View on GitHub (pinned to e1e7af627c)
Solutions
- Write a one-line description of the failure in the string.
- If the message is built dynamically, guard it so it is never empty when thrown.
- Add a lint step (`oxlint` with unicorn) to CI so placeholder errors are caught before merge.
Example fix
// before
throw new Error('');
// after
throw new Error('Failed to load configuration'); Defensive patterns
Strategy: validation
Prevention
- Never throw empty-string messages; write at least a short failure description.
- If messages are built dynamically, default them to a meaningful constant instead of `''`.
- Search the codebase for `Error('')` and `` Error(``) `` patterns during error-handling audits.
When it happens
Trigger: `throw new Error('')` or `` throw new Error(``) `` — the argument at the message position is a string literal with empty value. Only literals are checked; an empty-but-computed expression like `new Error(msg)` is not flagged.
Common situations: Placeholder errors written during development and never filled in; refactors that removed the message text but left the quotes; generated code that defaults messages to empty strings.
Related errors
- Pass a message to the {ctor_name:1} constructor.
- Invalid class name, use `{expected}`.
- Missing call to `super()` in constructor.
- The `name` property should be set to `{name}`.
- Error message should be a string.
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/8e9f1726d290188a.
Report an issue: GitHub.