no-unreachable: break after continue in switch statement incorrectly flagged
See original GitHub issue/* eslint no-unreachable: 2 */
var node = document.body.childNodes[0], visibleNodes = [], miscNodes = []
while (node = node.nextSibling) {
switch (node.nodeType) {
case Node.ELEMENT_NODE:
nodes.push(node);
break;
case Node.TEXT_NODE:
nodes.push(node);
break;
case Node.COMMENT_NODE:
continue; // refers to the while() loop, will not terminate execution in this case
break; // triggers no-unreachable
default:
miscNodes.push(node);
}
}
Reported in 2.0.0-beta.3
Seems to be a regression from https://github.com/eslint/eslint/issues/1220 / https://github.com/eslint/eslint/pull/1221
Issue Analytics
- State:
- Created 8 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Unreachable code error when I use a break in my switch ...
Meaning without break code execution will continue from matching case to next cases unless a break, return etc is encountered.
Read more >Documentation - TypeScript 1.8
Statements guaranteed to not be executed at run time are now correctly flagged as unreachable code errors. For instance, statements following unconditional ...
Read more >Why is it write "unreachable break after return"?
Therefore, a break (or any code following directly after a return statement will never be reached and makes the code hard to read...
Read more >MSC12-C. Detect and remove code that has no effect
Code that has no effect or is never executed (that is, dead or unreachable code) is typically the result of a coding error...
Read more >PhpStorm - Code Inspections in JavaScript and TypeScript
This is usually the case if the imported symbols are not used in the ... Reports a common mistake in TypeScript code, when...
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
@gheljenor To avoid that issue, you should enable the
no-fallthrough
rule.May i reopen this?
In this case
break;
is not really needed, but… Imagine such case of refactoring:Then we decide, to decorate output and do something like this:
If there is no rule ‘no-fallthrough’ - we’ll break our code. It seems, better to keep
break;
statements in switch-case, even they are unreachable.