Timeline for Requiring Explicit Null Reference Handling
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 24, 2014 at 17:20 | comment | added | supercat |
...allowing null keys through to the IEqualityComparer would expose that object's null-related exceptions to the dictionary's client. To avoid that, Dictionary disallows null keys even though there's no other reason it should have to regard null keys as having a different meaning from any other kind.
|
|
| Feb 24, 2014 at 17:16 | comment | added | supercat |
One of the advantages of having an exception mechanism is that it can free one from cluttering up the main-line code with logic to check errors which it wouldn't be able to handle except by aborting the current operation. While an NRE is often annoyingly uninformative, trying to turn NREs into ANEs can cause issues of its own. For example, if the IEqualityComparer associated with a Dictionary wouldn't have trouble with a null key, there's no reason the Dictionary should either, but since the Dictionary doesn't know whether its IEqualityComparer will work with null keys...
|
|
| Mar 23, 2013 at 16:07 | comment | added | mortalapeman | I understand your point and it is perfectly valid. It is idiomatic C# to do as you are suggesting. I mean that one can write FirstOrDefault knowing that null is not an exceptional case, but then fail to provide null handling at the time for one reason or another. Granted that is the developers own fault, but why not make it harder to make that mistake? | |
| Mar 23, 2013 at 15:34 | comment | added | Doc Brown |
@mortalapeman: you did not get my point - missing error handling for null refs leads to an uncaught exception, missing error handling for exceptions obviously, too. You cannot have been "bitten by FirstOrDefault" more than by First without Default, that is technically impossible in C#.
|
|
| Mar 23, 2013 at 14:48 | comment | added | mortalapeman | I completely agree that writing tests is a much better solution. However, I can't force consumers of an api to write tests at compile time. By requiring null handling before returning the desired value, it is an explicit reminder to write a test for handling null references. I've been bitten by "FunctionOrDefault" a few too many times. | |
| Mar 23, 2013 at 13:10 | comment | added | Michael Shaw | I don't understand why this would be over-engineering. | |
| Mar 23, 2013 at 10:56 | history | edited | Doc Brown | CC BY-SA 3.0 |
words improved
|
| Mar 23, 2013 at 10:51 | history | answered | Doc Brown | CC BY-SA 3.0 |