{"record":{"id":"7d9b80ba493173ea","repo":"oxc-project/oxc","slug":"require-a-message-for-matcher-name","errorCode":null,"errorMessage":"Require a message for {matcher_name:?}.","messagePattern":"Require a message for (.+?)\\.","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"warning","filePath":"crates/oxc_linter/src/rules/shared/jest_vitest/require_to_throw_message.rs","lineNumber":11,"sourceCode":"use oxc_ast::AstKind;\nuse oxc_diagnostics::OxcDiagnostic;\nuse oxc_span::Span;\n\nuse crate::{\n    context::LintContext,\n    utils::{PossibleJestNode, parse_expect_jest_fn_call},\n};\n\nfn require_to_throw_message_diagnostic(matcher_name: &str, span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(format!(\"Require a message for {matcher_name:?}.\"))\n        .with_help(format!(\"Add an error message to {matcher_name:?}\"))\n        .with_label(span)\n}\n\npub const DOCUMENTATION: &str = r\"### What it does\n\nThis rule triggers a warning if `toThrow()` or `toThrowError()` is used without an error message.\n\n### Why is this bad?\n\nUsing `toThrow()` or `toThrowError()` without specifying an expected error message\nmakes tests less specific and harder to debug. When a test only checks that an\nerror was thrown but not what kind of error, it can pass even when the wrong\nerror is thrown, potentially hiding bugs. Providing an expected error message\nor error type makes tests more precise and helps catch regressions more effectively.\n\n### Examples\n","sourceCodeStart":1,"sourceCodeEnd":29,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/shared/jest_vitest/require_to_throw_message.rs#L1-L29","documentation":"Diagnostic from oxlint's shared jest/vitest require-to-throw-message rule. `toThrow()` / `toThrowError()` with no argument passes for ANY thrown value, so the test neither pins the failure mode nor explains intent; when it breaks you cannot tell whether the right error occurred. The rule reports argument-less toThrow/toThrowError matchers on parsed `expect(...)` calls and asks for a message, and formats the matcher name into both the message and help.","triggerScenarios":"A jest/vitest expect chain ending in `.toThrow()` or `.toThrowError()` with zero arguments: `expect(() => parse(bad)).toThrow();`, `await expect(fetch()).rejects.toThrowError();`. Passing a string, regex, class, or object (e.g. `{ message: 'Invalid input' }`) clears the rule.","commonSituations":"Placeholder assertions written to make a suite pass; teams inheriting suites where errors are unspecified; deleting a message during refactor; a11y of failure output — CI logs that just say 'thrown' without which error.","solutions":["Assert the specific failure: pass a substring, regex, or error class — `.toThrow('Unable to parse input')`, `.toThrow(TypeError)`, `.toThrow(/^Invalid/)`.","For async rejects, keep the argument on `.rejects.toThrow('...')`.","If matching any error is genuinely intended, disable the rule for that line (`// oxlint-disable-next-line jest/require-to-throw-message`)."],"exampleFix":"// before\nexpect(() => parse(badInput)).toThrow();\n\n// after\nexpect(() => parse(badInput)).toThrow('Unable to parse input');","handlingStrategy":"validation","validationCode":"oxlint --jest-plugin test/ # require-to-throw-message","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Always pass an expected message, regex, or error class to toThrow/toThrowError.","For dynamic messages, use a regex: .toThrow(/^Invalid input: /).","If any-thrown is intentional, annotate the suppression with a reason so the next reader knows."],"tags":["jest","vitest","assertions","testing","oxlint","lint"],"backgroundTag":"assertion-message-missing","analyzedSha":"e1e7af627c8843ab64044ed466b128fcc21a035b","analyzedAt":"2026-08-20T07:01:07.079Z","contentChangedAt":"2026-08-20T07:01:07.079Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}