Closed
Description
Motivation:
Here’s the scenario:
- We have a
Weapon
class with a methodisMassDestruction()
that returnsfalse
by default. The subclassNuclearBomb
overrides this method to returntrue
. - During a refactor, the method
isMassDestruction()
was renamed toisDestructive()
in theWeapon
class. - We updated the method in
NuclearBomb
, but we missed theoverride_on_non_overriding_member
warning, as it was just one of 3,737 warnings and 1777 hints. (we have lots of auto generated code) - The method in
NuclearBomb
wasn’t updated to the new name, and, there were not analyzer error, the bug reached production, it caused a critical bug, leading to a nuclear bomb explosion in the app.
Here's the code:
class Weapon {
bool isMassDestruction() {
return false;
}
}
class NuclearBomb extends Weapon {
@override
bool isMassDestruction() {
return true;
}
}
After the refactor, the code became:
class Weapon {
bool isDestructive() {
return false;
}
}
class NuclearBomb extends Weapon {
@override
bool isMassDestruction() {
return true; // This is the old method name, which wasn't updated
}
}
Discussion
One may argue that the developer should do the shore of cleaning up warnings and info. And Yes, there is already a way to turn the linter rule into an error with following:
linter:
rules:
override_on_non_overriding_member: true
analyzer:
errors:
override_on_non_overriding_member: error
However, having override_on_non_overriding_member
flag raised, wether it be an error, warning or info in almost all case suggest a bug. Therefore, I believe it should be turned into a keyword. And prevent the application from compiling if the rule is raised. (much like how @required
once was not a keyword)
Many programming language already behave as per the proposal.
Metadata
Metadata
Assignees
Labels
No labels