Checking for null from another method

In C#, when I try to check for nulls outside the current method, somehow the compiler does not understand what is going on at compile time. For instance, consider this method:

public static class Guard {
     public static void ThrowIfNull(params object?[] args) {
         foreach(var arg in args) {
             ArgumentNullException.ThrowIfNull(arg);
         }
     }
}

When I use this method to actually validate parameters of another method, let's say:

public void TestCase(string? name, string? email) {
    Guard.ThrowIfNull(name, email);
    
    string _name = name;
    string _email = email;
}

The compiler does not understand this null check, and I still get the nullable warning.

The problem here is a few things:

1. I am not interested in null suppression by using ! after the null check
2. Moving ArgumentNullException.ThrowIfNull(arg); inside the method actually makes the code ugly
3. I cannot use the NotNull attribute on the params array because C# does not understand that I actually mean NotNull for each index of the array

Now how should this problem be solved?

First off, arrays are harder to check for nullability, hence you should favor another solution.

Secondly, I personally prefer to throw "in place" instead to use a function. That's because is useful to see which parameter is null (i.e. I want the see its name). Something like this:

public void TestCase(string? name, string? email)
{
    string _name = name ?? throw new ArgumentNullException(nameof(name));
    string _email = email ?? throw new ArgumentNullException(nameof(email));
}

Finally, have a look on how the ArgumentNullException.ThrowIfNull(arg) is internally written. That will give a hint:

    public static void ThrowIfNull(
        [NotNull] object? argument, 
        [CallerArgumentExpression("argument")] string? paramName = null
        )
    {
        if (argument is null)
        {
            Throw(paramName);
        }
    }

That is, the [NotNull] attribute does the job you need.

That being said, I'd rewrite your code as follows:

public static class Guard
{
    public static void ThrowIfNull([NotNull] object? arg)
    {
        ArgumentNullException.ThrowIfNull(arg);
    }

    public static void ThrowIfNull([NotNull] object? arg1, [NotNull] object? arg2)
    {
        ArgumentNullException.ThrowIfNull(arg1);
        ArgumentNullException.ThrowIfNull(arg2);
    }

    public static void ThrowIfNull([NotNull] object? arg1, [NotNull] object? arg2, [NotNull] object? arg3)
    {
        ArgumentNullException.ThrowIfNull(arg1);
        ArgumentNullException.ThrowIfNull(arg2);
        ArgumentNullException.ThrowIfNull(arg3);
    }

    // ...etc...
}

The piece under test shows no more warning:

    public void TestCase(string? name, string? email)
    {
        Guard.ThrowIfNull(name, email);

        string _name = name;    //no warning
        string _email = email;  //no warning
    }

Unfortunately (as others have pointed out) you cannot achieve this with params.

I guess you want to avoid "ugly" code where you have to call ArgumentNullException.ThrowIfNull() for each parameter separately.

In this case you could write a separate method for each number of arguments that you want to check. Alas, you can't overload these methods if you are using [CallerArgumentExpression] to specify the argument names because the compiler will select the overload with the fewest parameters rather than the one you want.

However, given those restrictions you can write something like this:

public static class MyArgumentNullException
{
    public static void ThrowIf1Null([NotNull] object? arg, [CallerArgumentExpression("arg")] string? argName = null)
    {
        if (arg == null) 
            throw new ArgumentNullException(argName);
    }

    public static void ThrowIf2Null(
        [NotNull]                          object? arg1,
        [NotNull]                          object? arg2,
        [CallerArgumentExpression("arg1")] string? argName1 = null,
        [CallerArgumentExpression("arg2")] string? argName2 = null)
    {
        if (arg1 == null)
            throw new ArgumentNullException(argName1);

        if (arg2 == null)
            throw new ArgumentNullException(argName2);
    }

    public static void ThrowIf3Null(
        [NotNull]                          object? arg1,
        [NotNull]                          object? arg2,
        [NotNull]                          object? arg3,
        [CallerArgumentExpression("arg1")] string? argName1 = null,
        [CallerArgumentExpression("arg2")] string? argName2 = null,
        [CallerArgumentExpression("arg3")] string? argName3 = null)
    {
        if (arg1 == null)
            throw new ArgumentNullException(argName1);

        if (arg2 == null)
            throw new ArgumentNullException(argName2);

        if (arg3 == null)
            throw new ArgumentNullException(argName3);
    }

    // And so on for all the paraneters you want.
}

Then you can write code like this:

public static class Program
{
    public static void Main()
    {
        // This throws with message:
        // "Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'u')"
        Test("a", "b", null!);
    }

    public static void Test(string s, string t, string u)
    {
        MyArgumentNullException.ThrowIf3Null(s, t, u);

        Console.WriteLine(s.Length + t.Length + u.Length);
    }
}

The final answer to the question is that, there is no way to define to the C# compiler that the null check is taking place in the other method. This leads to the conclusion that using nullable reference types actually brings a few problems to the code:

1. Null checks cannot be handled centrally. Without such feature, all methods have to individually check for nulls which makes the code lengthier and uglier.
2. It is absolutely pointless to suppress null warnings using the ! operator.
3. False positive reports can be generated by security scanning and code analysis tools if null checks are not done in the right place (which as I explained earlier makes the code ugly).

This feature seems to be either badly designed or incomplete at the time I posted this answer.