Yesterday I upgraded to Elements 12.0.0.2959 and my code became unstable.
I found out that the expression
s.IndexOf(“something”), when s = “”, started raising “System.ArgumentException: Input value cannot be nil or empty”. While this would be logical if s = nil, it makes no sense with an empty string.
See the attached project.
TestIndexOf.zip (725.6 KB)
This is as designed; note how the message explicitly mentiones both nil and empty (as thiose are conceptually simialr/identical for the purpose of this check).
Message: Input value cannot be nil or empty.
There’s no sense in checking for the occurence of an “empty” string within an other string, really? Although I suppose one could get philosophical about it. Are there emtpy stings between all the characters?
Note that this refes to the value you a re LOOKING FOR being empty, niot the value you are LOOKING IN
"".IndexOf("foo");
is fine, and will be -1 (not found)
"foo".IndexOf("");
is not, as you cannot search for “nothing”.
In your test case, you’re using the same string, "" for both call site and parameter, but it’s the use of it as parameter that’s triggering the exception.
Thanks. My bad, I thought it was the left-hand string causing the trouble.
Anyway, this didn’t crash in my previous installed version of Elements (which was quite a few releases behind). The philosophy has definitely changed since.
Yes, the ezact handlig chnaged in September; before this one only failed for nil, and not empty. I cleaned this up ad part of other fixes to nil/empty not being handled cosistently in IndexOf and Replace.