>>110309138
Claude is at it again...
What you're saying is not correct, the following will not compile and is therefore a non issue.
DataAccess access = new(new(null));
Claude:
That one’s interesting. The inner new(null) is target-typed to string, so it’s new string(null). That most likely binds to the string(char[] value) constructor, which is documented to return an empty string when value is null.
So it compiles without any nullable warning, because the argument the compiler sees is a non-null string. The key you actually pass is "", and the lookup fails at runtime. This is exactly the case the compiler can’t catch, and it’s why the constructor guard is useful:
ArgumentException.ThrowIfNullOrWhiteSpace(connectionKey);
User:
but this does not compile
DataAccess access = new(new(null));
It gives an Ambiguous constructor reference.
Claude:
Reviewing the earlier reply's claim about null handling.
You’re right, and I led with the wrong outcome. null converts to all four of those parameter types, and none of them is a better match than the others, so the compiler reports the call as ambiguous instead of picking char[].
If you cast null to pick one constructor, it compiles, and the result is what I described:
DataAccess access = new(new string((char[]?)null)); // key is ""
The compiler sees a non-null string, so there’s no warning, but the key you pass is empty. In practice the more realistic version of this is just new("") or a key read from config that turns out to be blank. Either way, ThrowIfNullOrWhiteSpace in the constructor is what catches it.
User:
but this is an insane edge case. What user would ever use that?
Claude:
Agreed, nobody writes new string((char[]?)null). I went too far down that path. ThrowIfNullOrWhiteSpace would only start to pay off if the key ever came from outside the code, like a command-line argument or a config value.
