Timeline for Is a new Boolean field better than a null reference when a value can be meaningfully absent?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 1, 2019 at 7:59 | vote | accept | ocomfd | ||
| Feb 27, 2019 at 10:32 | comment | added | Frank Hopkins | @ChristianHackl yes, depends on what you want to do concretely, if you just want to make sure the consumer can properly operate on an object it retrieves, it would suffice if it retrieves it, does a null check and then operates on it; if it shouldn't operate on it when it has become null inside the component providing it, then it gets a lot more complicated. But I guess the details are out of scope for the question, yet, I'd find it relevant to point out that there are other problems waiting for you in a concurrent scenario, as it's often enough forgotten ;) | |
| Feb 27, 2019 at 9:53 | comment | added | Christian Hackl | @Flater: It's a matter of how easy the compiler makes it for you to do the wrong thing. Forgetting to check for null in Java is very easy, because the syntax of the programming language allows you to use the object anyway. Forgetting an isPresent check is not so easy, because you have to actively access the underlying object with get. IOW, getPossiblyNullObject().doSomething() is a potential runtime error, whereas getOptionalObject().doSomething() is a compilation error. You have to write getOptionalObject().get().doSomething(), and this piece of code already signals a problem. | |
| Feb 27, 2019 at 9:21 | comment | added | Flater | @GiacomoAlzetta: The consumer will have to account for non-existence. Whether that's through a null check or an "exists" check is irrelevant - it requires an active effort and without it errors or unexpected behavior are always ready to occur. The issue with null is that it's being used excessively and often leads to a less meaningful null reference as opposed to a clear error (e.g. cannot find X), not that the usage of null should be avoided entirely. | |
| Feb 27, 2019 at 8:14 | comment | added | Giacomo Alzetta | @Flater I'd disagree there. If absence of value is a valid state Optional/Maybe is superior to just using null because it forces the caller to handle the no-value case properly. Returning null doesn't and someone can always forget to check for it and the bug might become apparent only after a long amount of time. Then: if you are writing in a language that does little to no compile-time checks than there isn't a big difference... but why use a statically checked language if you then decide to actively avoid the safety that the compiler could easily provide? | |
| Feb 27, 2019 at 5:30 | comment | added | Christian Hackl | @FrankHopkins: Good point, but if concurrency is used, even the inspection of a single variable may require locking. | |
| Feb 26, 2019 at 20:12 | comment | added | Frank Hopkins | However, there is one potential drawback of a separate function (that applies to the original suggestion as well): concurrency. If you are running in a framework where concurrency is important and your value could change from having a value to having no value, you can easily run into a problem when first checking via the 'isPasswordChanged' method and, when it returns true, retrieving the object and without further check trying to access it. So you need to figure out first whether concurrency is an issue where this code is supposed to be used. | |
| Feb 26, 2019 at 20:12 | comment | added | Gherman | @FrankHopkins he is not lost either way. Checking could be forced somehow. | |
| Feb 26, 2019 at 20:04 | comment | added | TZHX | @Gherman IMO it provides a benefit in the readability of the code by providing more meaning/context — of course if you are writing new code against the class it doesn’t force you to use it. Giving the null-condition a meaningful name does more good than harm. | |
| Feb 26, 2019 at 19:55 | comment | added | Frank Hopkins | @Gherman If the consumer doesn't get the concept that null is meaningful or that he needs to check for the value being present, he is lost either way, but if the method is used, it is clear to everyone reading the code why there is a check and that there is a reasonable chance that the value is null/not present. Otherwise it is unclear if it was just a developer adding a null check just "because why not" or whether it's part of the concept. Sure, one can find out, but one way you have the information directly the other you need to look into the implementation. | |
| Feb 26, 2019 at 17:01 | comment | added | Gherman | You could forget to call isPasswordChanged just like you can forget to check if it's null. I see nothing gained here. | |
| Feb 26, 2019 at 10:24 | comment | added | Bent | I would put it a little stronger as never have two variables that maintain the same state. It will fail. Hiding a null value, assuming the null value makes sense inside the instance, from the outside is a very good thing. In this case where you may later decide that 1970-01-01 denotes that the password has never been changed. Then the logic of the rest of the program does not have to care. | |
| Feb 26, 2019 at 9:29 | comment | added | Flater | +1 for the opening. Wanton usage of null is generally disapproved of only in cases where null is an unexpected outcome, i.e. where it wouldn't make sense (to a consumer). If null is meaningful, then it's not an unexpected outcome. | |
| Feb 26, 2019 at 8:50 | history | answered | TZHX | CC BY-SA 4.0 |