Dereference of a possibly null reference using Guards

Question

It's been a while since I've been deep into C#. Last time I used it I was using VS 2019. Back then I used to use a fluent validation library called Dawn Guard, to validate arguments incoming to methods and so forth. But Dawn Guard has apparently fallen to the way side and is no longer supported. The next recommendation for the same functionality was .net Guard which works very similarly. This all worked just fine in 2019, I even had code snippets so I could validate anything I might pass around. All of a sudden the new visual studio marks it with a warning.

 [STAThread]
 static void Main(string[] args)
 {
     var host = InitializeDependencyInjection(args);

     var master_form = default(IForm);

     try
     {
         master_form = host.Services.GetService<IForm>();
         Guard.NotNull(master_form, nameof(master_form));

         Application.Run(master_form.getForm());
     }
     catch(Exception ex)
     {
         MessageBox.Show(ex.Message);
     }
 }

When I make a call and use a guard statement on the return value, I am getting a warning of CS8602 'Dereference of a possibly null reference' on the Application.Run() line.

I don't want to turn off the warning. Warnings are a sign that something bad is going to swim up and bite you later and you need to fix it. But because of the Guard statement it is 'impossible' for the null reference to occur because the Guard will throw an exception if it is.

obviously I could do the ? check to eliminate the warning but i shouldn't have to because there's no normal way for the object to be null past the check

            Application.Run(master_form?.GetForm());

Does anyone have any idea how to make vs 2022 recognize this?

Answer 1

One option is to fork the Guard.NotNull code from DawnGuard to add nullable annotation attributes to it, such as the [NotNull] attribute. You don't necessarily need to maintain the whole project, you could fork the code locally into your solution and just maintain it for yourself.

If forking the whole project is out of scope, you could also write your own Guard class with a NotNull and whichever other methods you depend upon.

The benefit of fixing this for yourself is that you don't have to use ?. or !. throughout the rest of your code when you know you've checked for null (presumably you use Guard more than once).