Timeline for What should be the last entry in a switch/case statement?
Current License: CC BY-SA 4.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 20, 2018 at 8:50 | comment | added | amon | Switches and enums differ radically between languages so I don't think there can be a language-agnostic answer. E.g. some languages can guarantee that no switch is non-exhaustive or has unreachable branches, in which case the future-proofing argument doesn't apply. | |
| Jul 19, 2018 at 20:29 | comment | added | kamikaze | Handling a case that should never happen is called defense in depth. I consider it good practice, but I don't use an exception I just add an ’assert(!"explain why this should not happen")’. | |
| Jul 19, 2018 at 19:25 | comment | added | StackOverFowl | Switch statement might be generating an abstract factory and require a default implementation if none provided. You wouldn’t want your animal factory to default to no animals would you? Car factory? Burger factory? You are thinking of case statement if a user would provide input but that is not always the case: default thinking. | |
| Jul 19, 2018 at 17:27 | comment | added | Robert Harvey | @Eric: Yeah, I never made that assertion, nor would I. People make mistakes. The one where someone adds an item to an enum but forgets to add a case to a switch statement will become abundantly obvious when the unit test for the new case fails. | |
| Jul 19, 2018 at 17:25 | comment | added | Eric | @RobertHarvey No, but if programmers just did what they were supposed to do, we could. A programmer's job is not to create bugs after all. | |
| Jul 19, 2018 at 17:24 | comment | added | Robert Harvey | @Eric: Um, what? You're not actually proposing that always putting a default case in a switch statement would allow us to do that, are you? | |
| Jul 19, 2018 at 17:23 | comment | added | Eric | @RobertHarvey Yes, imagine all the money we could save by firing all the QA staff and how much more productive we could be without writing all those pesky unit tests. | |
| Jul 19, 2018 at 17:22 | comment | added | Robert Harvey | @Dev-iL: I'm not going to tell anyone that they have to do anything. We already have too many people in our industry that can't think for themselves. | |
| Jul 19, 2018 at 17:20 | comment | added | Dev-iL | @RobertHarvey, yes but Defensive programming :) | |
| Jul 19, 2018 at 17:20 | comment | added | Robert Harvey | @Eric: Then you need it, so put it in. If your code base has enums that are going to change frequently without your developers going back and checking all of the places where they are used, then by all means, put it in. Wouldn't it be better if the developers did what they're supposed to do? | |
| Jul 19, 2018 at 17:12 | comment | added | Eric | @RobertHarvey Approach 3 is the only sensible choice given that enums change over time and can be derived from poorly controlled sources like deserialization. | |
| Jul 19, 2018 at 17:06 | answer | added | Aphton | timeline score: 0 | |
| Jul 19, 2018 at 17:04 | vote | accept | Dev-iL | ||
| Jul 19, 2018 at 17:01 | review | Close votes | |||
| Jul 24, 2018 at 3:01 | |||||
| Jul 19, 2018 at 16:54 | answer | added | Greg Burghardt | timeline score: 7 | |
| Jul 19, 2018 at 16:28 | answer | added | gnovice | timeline score: 0 | |
| Jul 19, 2018 at 16:21 | comment | added | Robert Harvey | Then you need it, so put it in. If your peace of mind requires the default case, by all means, put it in. | |
| Jul 19, 2018 at 16:19 | comment | added | Dev-iL | Perhaps I misunderstand - but why don't I need it? If I get an unexpected value, I'd like to know that my code didn't handle/recognize it at all, instead of silently skipping the entire switch block (which is what happens when none of the cases were met and there's no default). As you said in your now-deleted comment, this can be solved with an assert(isValueInExpectedRange(val)), but then it might be difficult to validate the value... | |
| Jul 19, 2018 at 16:14 | comment | added | Robert Harvey | Approach 3 is a "you don't need one" case. | |
| Jul 19, 2018 at 15:59 | comment | added | Dev-iL | @RobertHarvey Would you be able to elaborate please? If it's just the "comical" aspect of the exception, it can obviously be turned into a more meaningful "UnhandledScenarioException" etc. | |
| Jul 19, 2018 at 15:55 | comment | added | Robert Harvey | I would avoid approach 3. | |
| Jul 19, 2018 at 15:52 | comment | added | Dev-iL | @RobertHarvey So what you're saying, in other words, is that I should consider these options each time and decide on a per-case basis? Would you say that all approaches are equally valid? | |
| Jul 19, 2018 at 15:45 | answer | added | Ewan | timeline score: 2 | |
| Jul 19, 2018 at 15:42 | comment | added | Robert Harvey | Sorry, but being a software developer requires you to think. The correct answer is "use a default case when you need one." | |
| Jul 19, 2018 at 15:40 | history | asked | Dev-iL | CC BY-SA 4.0 |