.NET's Sometimes Nonsensical Logic
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
I can see what you mean, but I can see the logic as well -- so I agree with MS on this. With Any, you begin by setting the result to false, then iterate the tests, if any of the tests is true, you return true -- so no tests yields false. With All, you begin by setting the result to true, then iterate the tests, if any of the tests is false, you return false -- so no tests yields true. Both have a short-circuit feature, which is a good thing. I definitely agree that MS needed to have a more cohesive development team who communicated and decided on things like this.
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
Peter Moore - Chicago wrote:
If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES?
Maybe MS's approach is, "[nobody said no](https://www.youtube.com/watch?v=duRoyOX8VSw)".
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
I'm with MS on this one:
Allis basically saying "If any of the people in this room do not match this condition return false""I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
There are certainly some odd decisions in the .NET class libraries. But I don't agree with you on this one. From a purely logical perspective, checking whether all members of an empty set satisfy a particular condition should always return
true- there are no members which don't satisfy the condition, so returningfalsewould be senseless. If you want an example of a nonsensical decision, look no further than theSystem.Text.Json.JsonElement'sTryGet...methods, which will throw an exception if the "JSON type" of the element is wrong. SoTryGetInt64will returntruefor{ "id": 42 }; returnfalsefor{ "id": 3.1415 }; and throw an exception for{ "id": "42" }. :wtf: Given the usualTryParsepattern, you might expect these methods to returnfalsefor any invalid input. But that's not what they do. They returnfalsefor some kinds of invalid input, and throw an exception for other kinds of invalid input.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I can see what you mean, but I can see the logic as well -- so I agree with MS on this. With Any, you begin by setting the result to false, then iterate the tests, if any of the tests is true, you return true -- so no tests yields false. With All, you begin by setting the result to true, then iterate the tests, if any of the tests is false, you return false -- so no tests yields true. Both have a short-circuit feature, which is a good thing. I definitely agree that MS needed to have a more cohesive development team who communicated and decided on things like this.
Well look I'm not saying there's no good *argument* in favor of `[Empty].All()` returning `true`, and I totally get the programming logic of starting with `true` and breaking if and only if you find a `false`. It's not like the decision is unjustifiable. But I think the "Right Thing" to do here is more than sufficiently debatable that if ever there was a time to throw an exception (which they love to do in countless other contexts) it would be here.
-
There are certainly some odd decisions in the .NET class libraries. But I don't agree with you on this one. From a purely logical perspective, checking whether all members of an empty set satisfy a particular condition should always return
true- there are no members which don't satisfy the condition, so returningfalsewould be senseless. If you want an example of a nonsensical decision, look no further than theSystem.Text.Json.JsonElement'sTryGet...methods, which will throw an exception if the "JSON type" of the element is wrong. SoTryGetInt64will returntruefor{ "id": 42 }; returnfalsefor{ "id": 3.1415 }; and throw an exception for{ "id": "42" }. :wtf: Given the usualTryParsepattern, you might expect these methods to returnfalsefor any invalid input. But that's not what they do. They returnfalsefor some kinds of invalid input, and throw an exception for other kinds of invalid input.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
There are certainly some odd decisions in the .NET class libraries. But I don't agree with you on this one. From a purely logical perspective, checking whether all members of an empty set satisfy a particular condition should always return
true- there are no members which don't satisfy the condition, so returningfalsewould be senseless. If you want an example of a nonsensical decision, look no further than theSystem.Text.Json.JsonElement'sTryGet...methods, which will throw an exception if the "JSON type" of the element is wrong. SoTryGetInt64will returntruefor{ "id": 42 }; returnfalsefor{ "id": 3.1415 }; and throw an exception for{ "id": "42" }. :wtf: Given the usualTryParsepattern, you might expect these methods to returnfalsefor any invalid input. But that's not what they do. They returnfalsefor some kinds of invalid input, and throw an exception for other kinds of invalid input.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
But also great example.
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
Here's a more obscure one. `HashAlgorithm.TransformBlock` is for computing things like MD5 and SHA hashes on streamable data. `TransformFinalBlock` needs to be called at the end, even if there's no data left to include in the hash. Notably you have to give it both an array AND the length. You can give it an empty `byte[]` and specify it has 0 length, and it's perfectly happy. But give it a `null` buffer - even if you specify 0 length! - and it throws on you. I'm explicitly telling it I have no data to give it, but I still have to give it the empty array, for reasons.
-
Well look I'm not saying there's no good *argument* in favor of `[Empty].All()` returning `true`, and I totally get the programming logic of starting with `true` and breaking if and only if you find a `false`. It's not like the decision is unjustifiable. But I think the "Right Thing" to do here is more than sufficiently debatable that if ever there was a time to throw an exception (which they love to do in countless other contexts) it would be here.
I disagree with throwing an exception for that an empty collection.
-
I disagree with throwing an exception for that an empty collection.
Only because you agree with their logic. Not everyone does. The ambiguity is the issue, not whether you or I agree with the decision.
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
In logic,
ALL(P(x))[would be equivalent to](https://en.wikipedia.org/wiki/First-order\_logic#Provable\_identities)NOT ANY(NOT P(x)). So if you agree on that[Empty].Any(...)would always be false, then it logically follows that[Empty].All(...)would be true. -
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
I agree. I find the behavior of
All()on an empty collection strange. If I'm told "all the members of a list of integers are greater than zero" I would expectAny(p => p > 0)on that list to returntrue. But if the list is empty,Any(p => p > 0)returnsfalse. That seems wrong. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
In logic,
ALL(P(x))[would be equivalent to](https://en.wikipedia.org/wiki/First-order\_logic#Provable\_identities)NOT ANY(NOT P(x)). So if you agree on that[Empty].Any(...)would always be false, then it logically follows that[Empty].All(...)would be true. -
In logic,
ALL(P(x))[would be equivalent to](https://en.wikipedia.org/wiki/First-order\_logic#Provable\_identities)NOT ANY(NOT P(x)). So if you agree on that[Empty].Any(...)would always be false, then it logically follows that[Empty].All(...)would be true.To add to this, what universality (All) is really saying is that "nothing exists that violates this constraint", whereas existentiality (Any) is really saying "at least one thing exists that obeys this constraint." With [].All(constraint), nothing exists to violate the constraint, so All() returns true. With [].Any(constraint), nothing exists to obey the constraint, so Any() returns false.
-
Yes, we have no bananas.... how about malloc( 0 ) not returning NULL.
"A little time, a little trouble, your better day" Badfinger
That was interesting. Apparently that is undefined so implementation dependent. I wonder why. I suspect some memory allocators would have trouble with allocating an empty block so perhaps that is the reason to allow null. What is additionally interesting was that I was thinking it would return just a pointer to the heap block tracker. That is so free still works. But of course it could actually return real space. So for example if the allocator just always sizes up to a block (say 16 bytes) it might be valid space.
-
That was interesting. Apparently that is undefined so implementation dependent. I wonder why. I suspect some memory allocators would have trouble with allocating an empty block so perhaps that is the reason to allow null. What is additionally interesting was that I was thinking it would return just a pointer to the heap block tracker. That is so free still works. But of course it could actually return real space. So for example if the allocator just always sizes up to a block (say 16 bytes) it might be valid space.
I brought it up a while back and there was some back and forth on it. Apparently, malloc( 0 ) not returning NULL is deliberate. Here is what GCC does with some short bit of code printf("Hello world!\n"); printf( "call malloc(0)\n" ); sz = (char*)malloc(ZERO); printf( "Errno %d\n", errno ); if( sz == NULL ) printf( "returned NULL allocated zero bytes\n"); else printf( "NULL not returned from malloc, allocated 8 bytes\n" ); Hello world! call malloc(0) Errno 0 NULL not returned from malloc, allocated 8 bytes Apparently this is allowed by GCC. The argument is that it was successful Haven't tried it in VS.
"A little time, a little trouble, your better day" Badfinger
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
I feel what you feel but! If you walk in a room and ask if anyone is there and there is no reply you have to note that down as false. If you walk in a room and ask if all of them are aliens, but no one denies (cause nobody there) you note that down as true. If there is no room you can walk into you can't ask questions in there, hence you trip and fall into the backrooms (nullException) So MS is right, although it seems a bit off.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
Would you think otherwise if the method were called `Every`?
No. :) Maybe its a mathematical mindset. "Is this condition true for every member of this (empty) set?" has to return
true, since there are no members of the set where the condition is not true. Similarly, "Is this condition true for any member of this (empty) set?" has to returnfalse, since there are no members of the set where the condition is true.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
.NET's behavior is similar to the Principle of explosion It is not a fallacy, it is a matter of "careful what you wish, you just might get it". If you ask for multiple elements to satisfy a condition, you should be aware that you are, in fact, asking 2 questions: 1. I want at least 1 element 2. Each one of them satisfies the criterion. Do not count on the tooth fairy to satisfy your hidden criterion #1, make it explicit instead.
