[no-unreachable] switch statement
See original GitHub issueWhen break
is used consistently to avoid programmer errors in the future, eslint will warn about having return
& break
(the break
being unreachable).
I think this is similar to the (redundant) trailing commas where they are preventing future errors so this should be allowed:
switch (cond) {
case 'one':
if (cond1)
return 'denied';
else
return 'good'
break; // <--- this will trigger the warning of unreachable code
case 'two':
simple code..
just statements..
break;
default:
return 'unexpected';
}
(note: it may also be a stylistic/formatting preference that all cases have break pairs)
Issue Analytics
- State:
- Created 8 years ago
- Comments:10 (6 by maintainers)
Top Results From Across the Web
Unreachable code error when I use a break in my switch ...
The linter rule i.e. 'no-fallthrough' in eslint, acts as to not allow any accidental fallthrough from case to case. Meaning without break ...
Read more >Unreachable Switch Statement Default Cases
Standard C and C++ requires switch statements to behave harmlessly if on a value that not covered by one of their case's.
Read more >Why is it write "unreachable break after return"? - Codecademy
a) using a break: that will make the programm jump out of the switch, returning nothing. b) using a return: that will make...
Read more >Unreachable 'case' branch of a 'switch' statement - JetBrains
Suppress an inspection in the editor. Position the caret at the highlighted line and press Alt+Enter or click the Intention action icon ....
Read more >no-unreachable - ESLint - Pluggable JavaScript Linter
/*eslint no-unreachable: "error"*/ function foo() { return bar(); function bar() { return 1; } } function bar() { return x; var x; }...
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 Free
Top 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
This may work as you guys intended, but then your intentions simply don’t cover all the cases. 😃 As with other rules it’s not always an on/off binary option, sometimes you need more options to have a reasonable setup.
Disabling globally or even around a switch is not a solution.
Consider the following example:
In the first case it makes no sense for ESLint to enforce the rule, but if you turn it off you lose the helpful warnings e.g. in the second case.
This is the solution that I use, and my story of the whole issue. I’m using eslint v.2.9.0.
For what it’s worth, if I don’t see “break” at the end of every switch/case, I get concerned. From my C-days, I am used to adding /* NOTREACHABLE */ or /* FALLTHROUGH */ inside switch/case if I’m intending something specific. Having support for something like this (“case” by “case”) seems beneficial.
Specifying:
… doesn’t help because it’s the final rule that applies to the whole .js file (the first no-unreachable is, in effect, ignored). This is, of course, by design.
Adding either eslint-disable-line or eslint-disable-next-line inside /* */ comments:
…doesn’t help either (yes, I tried all four possible places for it).
These, however, work (the use of // instead of /* */ for the comments is required – is that a bug?):
I hope that helps.
Harry.