CODEWITHSUNDEEP
c#asp.net-corec#-8.0nullable-reference-types
RexolinJohn
RexolinJohn

Reputation: 1

Proper implementation NRT in ASP.NET Core

I have few question about nullable reference types as part of C# 8.0 in ASP.NET Core MVC:

  1. When exist action with string parameter (public IActionResult Index(string message)) then parameter can be still null if is not passed to action. What is official solution to that problem? Still need to check null?

  2. When exist simple mutable model how can be properly modyfied to NRT? For example Scott Allen (https://odetocode.com/blogs/scott/archive/2019/08/07/think-twice-before-returning-null.aspx) propose to create NullUser. Is it correct? Maybe<T> sound also do not fitted for NRT. What is official solution for mutable and immutable models?

    public class User
{
    public int UserId { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public IEnumerable<Message> Messages { get; set; }
}

public class Message
{
    public int MessageId { get; set; }
    public string Text { get; set; }
}

  3. Now very often i use FirstOrDefault when want pull something from collections (and after check null). Collection is not null but can be empty and now when want to use First will thrown an exception what is bad cuz it is a action and want create just bad response without try (https://softwareengineering.stackexchange.com/questions/387674/c-8-non-nullable-references-and-the-try-pattern) and try-catch. Again Maybe<T> sound not as solution. What is official solution for this problem?

I know i do not need to avoid nulls but want to minimalize them and follow NRT cuz its sound like song of future

Upvotes: 0

Views: 322

Answers (1)

Chris Pratt
Chris Pratt

Reputation: 239300

You're making this far too difficult. Nullable reference types are just a compiler hint - a way of being more explicit about what you actually expect a piece of code to do. It really doesn't change how anything works.

For example, with the situation of an action param. If your string param can be null (not should be, but can be - that's important), then it should be string? instead. Action params are almost always optional, so they can certainly be null. The only exception is route param, since you won't actually arrive at this action unless the route param is filled with something. Assuming it's being filled via the query string, for example, then it can definitely be null, and you should use string? there. If you want to ensure that it's not null, then you'll need to employ a standard null guard:

if (message == null)
    return BadRequest();

Mutability also has nothing to do with this. Again, all you're doing is being explicit about whether a reference could be null. This also applies to your third question. There's always a potential that a query won't match a row in the database, which will then return null. Using First is not some way of ensuring that actual value is returned; it will simply throw an exception in that case, instead. In this situation, you should continue using FirstOrDefault, use User?/Message? (or just var), and then do a null check as you always have.

Upvotes: 2

Related Questions