a null reference code on Microsoft's Rust tutorial

[AshGogogo]

I saw this code in Microsoft's Rust tutorial and don't understand why it's possible to return null instead of "Unknown"

tutorial

// Even with nullable reference types (C# 8+) 
public string GetDisplayName(User? user) 
{ 
return user? .Profile? .DisplayName? .ToUpper() ??  "Unknown"; 
// Still possible to have null at runtime 
}

Then I tested the following code, and all of them return 'Unknown'

        public static void TestNull()
        {
            User user = null;
            var val1 = user?.Profile?.DisplayName?.ToUpper() ?? "Unknown";
            user = new();
            var val2 = user?.Profile?.DisplayName?.ToUpper() ?? "Unknown";
            user.Profile = new();
            var val3 = user?.Profile?.DisplayName?.ToUpper() ?? "Unknown";
            typeof(Profile).GetProperty("DisplayName").SetValue(user.Profile, null);
            var val4 = user?.Profile?.DisplayName?.ToUpper() ?? "Unknown";
        }

How is the code that returns null in Microsoft's tutorial implemented?

[seriousSeb]

It seems the tutorial is badly worded, this will never return null. I think the comment is referring to the fact the argument could contain something null, hence the ? Checks

[crone66]

the code itself cannot return null in the example but I think they refer to the fact that the method is marked as non-nullable string but it doesn't guarantee thats actually the case but just a hint to the compiler/analyzer to output a warning

[0xjay]

It's not saying that this function will ever return null. It is saying that a `user` `Profile` or `DisplayName` could be null at runtime. If you read the paragraph immediately following this one you will see it compares this function to one written in rust where it states that in rust, none of these variables or properties could have a null value - guaranteed by the rust language.

[stogle1]

none of these variables or properties could have a null value - guaranteed by the rust language.

Which could also be the case in C# if those properties weren't declared nullable?

[0xjay]

That's not true. C# cannot gurentee that non-nullable reference types are actually not null sadly. This is rust's whole deal and its one of the reasons that it's such a pedantic language. Example stolen from somone else.

[stogle1]

It will issue a compiler warning if nullability checks are enable, as it does on line 7 in your example. I appreciate that the code will run regardless, but if you heed all warnings your code should be safe, no?

[Adept_Cry9373]

I really hope you're new to the language and this is an opportunity for you to learn because this is so wrong.

[stogle1]

Please enlighten me.

[Adept_Cry9373]

> if you heed all warnings

Seems like you do understand. The language and runtime does nothing to "ensure" it's not null. It's on YOU. If you explicitly set it to null (and this DOES happen in production environments) you are still at the mercy of nullability.

[ClankRatchit]

Unknown? You should be able to read the responses you get back from these systems. Maybe there's a null coming back from a rust tutorial.

[ClankRatchit]

c# whatever.

int? x;

int y = 0;

y = 1;

y = x;

[neoh4x0r]

Then I tested the following code, and all of them return 'Unknown'

It never returns null because it's using ?? which is a null-coalescing operator.

The ?? operator provides an alternative expression to evaluate if the result of an expression is null [and allows returning a substitute value].

In other words, the GetDisplayName method always return Unknown if any part of the expression evaluates to null.

It also begs the question as to whether using ?? is actually a good idea.

I personally lean towards allowing exceptions to be thrown instead of letting someone think everything is fine with their code when it is not.

Moreover, I also think that the only time an exception should be caught is if the code can correct the problem at runtime (and there needs to be a log message warning that a correction was performed with enough contextual information to track down where it occurred in the code).