question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Ignore `catch` block in the `no-empty` rule

See original GitHub issue

Problem

The following is very common pattern when you don’t care about an exception:

try {
  foo();
} catch (err) {}

But it’s caught by the no-empty rule.

I want the rule to catch empty blocks, but ignore the catch block as it’s empty because it’s required by JS, not because I want it there.

I know I can put in a // empty comment there, but that feels like an unuseful reiteration of the obvious.

Possible solution 1

Ignore catch by default as it’s required to be empty and not really useful to require it not to be empty. This is the preferred solution.

Possible solution 2

Add an option that defines exceptions in the form of keywords:

{
  "no-empty": [2, {"exceptions": "catch"}]
}

Issue Analytics

  • State:closed
  • Created 8 years ago
  • Comments:15 (11 by maintainers)

github_iconTop GitHub Comments

4reactions
ilyavolodincommented, Jun 20, 2015

@sindresorhus We provide a way to customize this behavior, if I’m not mistaken this code will lint just fine

try {
    foo();
} catch(err) {
    // I want application to not crush, but don't care about the message
}

Any comment inside a block will mark it as non-empty. Leaving comments in the cases where you used try catch but ignoring cache is a good idea, if somebody else is going to be looking at your code. But in general, I do see your point.

3reactions
danny-andrewscommented, Aug 16, 2017

@sindresorhus

The following is very common pattern when you don’t care about an exception:

try {
  foo();
} catch (err) {}

This is a HORRIBLE, HORRIBLE pattern that, unfortunately, is very common in javascript. But it shouldn’t be perpetuated explicitly or implicitly. At the very least you should provide a comment explaining why you are ignoring that exception. Better yet, you should do an instanceof check to only ignore Errors of a certain type, and rethrow all others, which would also satisfy this rule.

p.s. Excuse me for the strong formatting, but good error handling is something I feel VERY STRONGLY about. 😄

Read more comments on GitHub >

github_iconTop Results From Across the Web

no-empty - ESLint - Pluggable JavaScript Linter
This rule disallows empty block statements. This rule ignores block statements which contain a comment (for example, in an empty catch or finally...
Read more >
disallow empty block statements (no-empty) - ESLint
This rule ignores block statements which contain a comment (for example, in an empty catch or finally block of a try statement to...
Read more >
Why are empty catch blocks a bad idea? - Stack Overflow
Usually empty try-catch is a bad idea because you are silently swallowing an error condition and then continuing execution.
Read more >
empty_catches - Dart
In general, empty catch blocks should be avoided. In cases where they are intended, a comment should be provided to explain why exceptions...
Read more >
Javadoc Comments - checkstyle
Checks the order of javadoc block-tags or javadoc tags. ... Ignore try block, but keep catch and finally blocks.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found