Add `ignore-catch` option to `no-empty`
See original GitHub issueWhat version of ESLint are you using? v2.7.0
Change proposal
I would like to propose an ignore-catch
option for the no-empty
rule that would not warn for empty catch blocks. This would allow users the option to have have the same behavior as the corresponding JSCS rule disallowEmptyBlocks. The description of said rule is, “Disallows empty blocks (except for catch blocks).”
I’d be willing to make this change if it’s accepted.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:4
- Comments:11 (10 by maintainers)
Top 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 >Reference - Configuration (ES6 and IS7) - support@intershop
Property Default (Development) Type
intershop.AuthenticationSecurity.Mode secure_cookie_preferred String
intershop.event.messengerClass String
intershop.event.multicastAddress 224.1.2.3 String
Read more >Optional Parameters - IBM
EMPTY|NOEMPTY: Specifies what action is to be taken for the catalog entries for the ... by the setting of the SCRATCH/NOSCRATCH parameter for...
Read more >Intro(2) - UnixWare 7 Documentation
In the fcntl routine, the setting or removing of record locks on a file cannot be ... Large file support can be added...
Read more >automatic generation and assessment of source code method ...
Wilcoxon Test Summary of experts and novices After adding the non- ... A line of code is counted if and only if it...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Duplicate of https://github.com/eslint/eslint/issues/2808 and #1841. I still think it’s a valid use-case though and it’s obvious now many users agree.
That sounds fine. Compatibility with JSCS is important for people who are coming over, so I think @kaicataldo’s suggestion is good. The only change I’d make is that we’ve tried to move away from dash-cased option names, so I’d prefer something like:
Where the default is
false
.