Timeline for If functions have to do null checks before doing the intended behaviour is this bad design?
Current License: CC BY-SA 4.0
29 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 7, 2018 at 5:52 | history | tweeted | twitter.com/StackSoftEng/status/1015473673954906112 | ||
| Jul 6, 2018 at 10:29 | review | Suggested edits | |||
| Jul 6, 2018 at 16:57 | |||||
| Jul 5, 2018 at 20:08 | review | Suggested edits | |||
| Jul 5, 2018 at 20:18 | |||||
| Jul 4, 2018 at 19:14 | review | Suggested edits | |||
| Jul 4, 2018 at 19:48 | |||||
| Jul 4, 2018 at 19:14 | comment | added | smci | The question seems specific to C#, and certainly the 'right' way to handle null (whether and which exception to raise, etc.) will be language-dependent. | |
| Jul 4, 2018 at 14:29 | comment | added | Thorbjørn Ravn Andersen | The runtime engine checks for null values when they are being used, but you probably don't want that. | |
| Jul 4, 2018 at 7:00 | comment | added | Mafii | This is one of the reasons why the C# language team wants to introduce nullable reference types (and non nullable ones) -> github.com/dotnet/csharplang/issues/36 | |
| Jul 4, 2018 at 6:00 | history | edited | Toon Krijthe | CC BY-SA 4.0 | edited body |
| Jul 3, 2018 at 20:48 | answer | added | dgnuff | timeline score: 4 | |
| Jul 3, 2018 at 19:35 | answer | added | Eric Lippert | timeline score: 14 | |
| Jul 3, 2018 at 17:22 | vote | accept | WDUK | ||
| Jul 3, 2018 at 14:39 | answer | added | Paddy | timeline score: 8 | |
| Jul 3, 2018 at 14:35 | comment | added | jrh | (the last kind of "Fox Moulder" coding can be costly, I usually reserve it for poorly documented 3rd party libraries, old, difficult to use code with a giant amount of state that can't be unit tested / refactored yet, code that's executed periodically or rapidly, or code for a situation where some kind of response is crucial and an invalid state would be better off at least sending an error message to the thing requesting the information than just crashing and closing the socket) | |
| Jul 3, 2018 at 14:23 | comment | added | jrh | ... Or the possible unusual third case here, let's say you went with the route where you don't allow _someEntity to be not null (e.g., in the constructor / using readonly), hypothetically if you are doing Fox Moulder programming and you just can't afford any risk at all, and you feel like it's in your best interest to have a recovery option for absolutely everything (even against a future developer not understanding that _someEntity can't be null), you could do something to indicate that this is an unexpected condition, then perform whatever recovery you set to get you out of it. | |
| Jul 3, 2018 at 14:18 | comment | added | jrh | ... if there is a valid reason to have a null entity, then the null check is reasonable. Now the design decision is in SetName, as in, is it safe for it to ignore the entity being null and just return? (e.g., because the entity is optional) Or is it better for it to throw an InvalidOperationException because you tried to rename something that doesn't exist? This particular design decision depends on whether or not the caller of SetName knows / cares the entity exists, or if it's okay / acceptable for it to say "well I tried to rename it" and give up... | |
| Jul 3, 2018 at 14:16 | comment | added | jrh | The answer depends on a few factors. The important question here is, "Is there a valid reason for _someEntity to be null" (or if you prefer, is a null _someEntity field a valid state for the object to be in?). My suggestions: If there's no reason for the class to hold a null value for this field: If you can, pass in the entity in the constructor and throw an exception there, if you can't provide it in the constructor, throw an exception in AssignEntity... | |
| Jul 3, 2018 at 12:40 | comment | added | JᴀʏMᴇᴇ | With C# 8 you would potentially never need to worry about null reference exceptions with the right settings turned on: blogs.msdn.microsoft.com/dotnet/2017/11/15/… | |
| Jul 3, 2018 at 12:12 | comment | added | mgarciaisaia | You can watch Gary Bernhardt's Boundaries talk about making a clear division between sanitizing data (ie, checking for nulls, etc) in an outer shell, and having an inner core system that doesn't have to care about that stuff - and just do its work. | |
| Jul 3, 2018 at 12:06 | answer | added | Herr Derb | timeline score: 4 | |
| Jul 3, 2018 at 5:18 | comment | added | Stack Exchange Broke The Law | Why is it null in the first place? Is it supposed to be null, or is it not supposed to be null? If someone accidentally passes null, what should happen and why? | |
| Jul 3, 2018 at 3:37 | comment | added | Sebastiaan van den Broek | Note that some languages do have the option to make this parameter contract explicit, e.g. Scala’s Option<Entity>. While you could still pass a null Option, that would clearly be a mistake of the caller. But an empty Option would be fine. | |
| Jul 3, 2018 at 1:35 | vote | accept | WDUK | ||
| Jul 3, 2018 at 17:22 | |||||
| Jul 2, 2018 at 22:13 | review | Close votes | |||
| Jul 7, 2018 at 3:05 | |||||
| Jul 2, 2018 at 21:10 | answer | added | null | timeline score: 23 | |
| Jul 2, 2018 at 21:10 | answer | added | David Arno | timeline score: 55 | |
| Jul 2, 2018 at 21:10 | answer | added | whatsisname | timeline score: 168 | |
| Jul 2, 2018 at 21:04 | comment | added | gnasher729 | What happens if I actually want someEntity to be Null? You decide what you want, either someEntity can be Null, or it can't, and then you write your code accordingly. If you want it never to be Null, you can replace checks with asserts. | |
| Jul 2, 2018 at 20:58 | comment | added | Robert Harvey | What happens when someone fails to do the null check and SetName throws an exception anyway? | |
| Jul 2, 2018 at 20:50 | history | asked | WDUK | CC BY-SA 4.0 |