多空值检查 vs 分支式单空值检查：Path.Combine代码实现疑问

The Context #

I was examining the source code of the System.IO.Path class in .NET Framework 4.7.1 RS3 and came across the null-check logic in the 4-argument Combine overload:

public static String Combine(String path1, String path2, String path3, String path4) 
{ 
    if (path1 == null || path2 == null || path3 == null || path4 == null) 
        throw new ArgumentNullException(
            (path1 == null) ? "path1" : 
            (path2 == null) ? "path2" : 
            (path3 == null) ? "path3" : "path4"); 
    // Rest of the method...
}

I'm wondering if using a branching null-check pattern like this would be more appropriate:

public static String Combine(String path1, String path2, String path3, String path4) 
{ 
    if (path1 == null) 
        throw new ArgumentNullException("path1"); 
    else if (path2 == null) 
        throw new ArgumentNullException("path2"); 
    else if (path3 == null) 
        throw new ArgumentNullException("path3"); 
    else if (path4 == null) 
        throw new ArgumentNullException("path4");
    // Rest of the method...
}

My Answer #

Great question—this boils down to a tradeoff between code compactness and readability/maintainability, which is a common debate in .NET codebases. Let's break this down:

Why Branching Checks Are Better (Modern Perspective)

• Readability first: The branching approach makes it immediately clear which parameter is being validated at each step. Any developer (even someone new to the codebase) can glance at the code and understand exactly which null argument triggers which exception. The nested ternary, by contrast, requires mentally parsing the conditional chain to map null values to parameter names—easy to mix up if you're in a hurry.
• Easier debugging: If you need to debug a null argument issue, you can set a breakpoint directly on the line checking path2 or path3 and hit it only when that specific parameter is null. With the ternary approach, you'd have to step through the conditional logic to figure out which parameter failed.
• Better maintainability: If the method ever gets updated (e.g., adding a fifth parameter), extending the branching checks is trivial—just add another else if block. Modifying the nested ternary increases the risk of introducing a logic error (like swapping the order of conditions).
• Aligns with modern .NET conventions: Later versions of .NET introduced ArgumentNullException.ThrowIfNull() (available in .NET 6+) to make parameter validation even more explicit. While that's not an option in .NET Framework 4.7.1, the branching pattern is a closer match to this modern, clear validation style.

Why the Ternary Approach Might Have Been Used

The only real argument for the nested ternary is code brevity. In the early days of .NET, some teams prioritized minimizing line count, especially in core framework classes. However, this benefit is negligible compared to the long-term costs of reduced readability.

In short: Yes, the branching null-check pattern is absolutely more appropriate for this scenario. It makes the code easier to read, debug, and maintain—all critical factors for a widely used framework method like Path.Combine.

内容的提问来源于stack exchange，提问作者Senthil Ramanathan