Summary
The suggestion fix for require-json-parse-try-catch wraps the offending statement in a try/catch whose body merely re-throws:
// require-json-parse-try-catch.ts:161
return fixer.replaceText(
stmt,
`try {\n${indent} ${stmtText}\n${indent}} catch (err) {\n${indent} throw err;\n${indent}}`
);The produced code is asserted verbatim across the test suite, e.g.:
try {
const data = JSON.parse(rawInput);
} catch (err) {
throw err;
}
Why this is a problem
- It adds zero handling.
catch (err) { throw err; } rethrows the identical error with the same stack semantics — the program behaves exactly as if there were no try/catch. The rule's stated intent is "avoid uncaught runtime failures", but the fix does not avoid anything; it just silences the linter.
- It introduces a different lint violation.
catch (e) { throw e; } is precisely what ESLint core's no-useless-catch (part of eslint:recommended) flags. The suggested fix trades one warning for another, and any project running the recommended set gets a new error from applying our suggestion.
- It trains the wrong pattern. Contributors who accept the suggestion learn a no-op idiom instead of real error handling.
Acceptance criteria
- The suggestion no longer emits a bare
catch (err) { throw err; }. Acceptable directions (pick one, document the choice):
- Emit a catch body that is meaningful by default — e.g.
catch (err) { throw new Error(\Failed to parse JSON: ${getErrorMessage(err)}`); }(contextual message via the establishedgetErrorMessage` helper), or
- Emit a catch body with an explicit
// TODO: handle parse failure placeholder plus a contextual rethrow, so applying the fix never produces no-useless-catch-violating code, or
- Replace the suggestion text with guidance only (message
useHelper already points to parseJsonWithRepair / parseJsonlContent) and drop the auto-wrap entirely if a safe meaningful default cannot be generated.
- Whatever is chosen, the emitted output must not be flagged by
no-useless-catch.
- Update the test fixtures (
require-json-parse-try-catch.test.ts) to the new expected output, including the deferred-callback nested cases.
Notes
Independent of the existing scope items #41962 (computed/indirect JSON.parse) and #41963 (deferred-callback ancestry); this is purely about the quality of the emitted fix.
Generated by 🤖 ESLint Refiner · 185.1 AIC · ⌖ 12.4 AIC · ⊞ 4.7K · ◷
Summary
The suggestion fix for
require-json-parse-try-catchwraps the offending statement in a try/catch whose body merely re-throws:The produced code is asserted verbatim across the test suite, e.g.:
Why this is a problem
catch (err) { throw err; }rethrows the identical error with the same stack semantics — the program behaves exactly as if there were no try/catch. The rule's stated intent is "avoid uncaught runtime failures", but the fix does not avoid anything; it just silences the linter.catch (e) { throw e; }is precisely what ESLint core'sno-useless-catch(part ofeslint:recommended) flags. The suggested fix trades one warning for another, and any project running the recommended set gets a new error from applying our suggestion.Acceptance criteria
catch (err) { throw err; }. Acceptable directions (pick one, document the choice):catch (err) { throw new Error(\Failed to parse JSON: ${getErrorMessage(err)}`); }(contextual message via the establishedgetErrorMessage` helper), or// TODO: handle parse failureplaceholder plus a contextual rethrow, so applying the fix never producesno-useless-catch-violating code, oruseHelperalready points toparseJsonWithRepair/parseJsonlContent) and drop the auto-wrap entirely if a safe meaningful default cannot be generated.no-useless-catch.require-json-parse-try-catch.test.ts) to the new expected output, including the deferred-callback nested cases.Notes
Independent of the existing scope items #41962 (computed/indirect
JSON.parse) and #41963 (deferred-callback ancestry); this is purely about the quality of the emitted fix.