Bits of .NET

🔧 The New Overload That Quietly Stole Calls From the Old One

C#’s overload resolution always prefers a non-params overload over a params array overload when both are an equally valid match for a call – which is exactly correct in isolation, but means adding a brand-new, more specific overload to an existing method group can silently redirect calls that used to go to the params version, without touching a single line at any of those call sites. Nothing fails to compile; the code just quietly starts doing something else.

🔎 The Problem

public static class Logger
{
    public static void Log(string message, params object[] args)
        => Console.WriteLine(string.Format(message, args));
}

// Every call site in the codebase uses this form:
Logger.Log("User {0} failed with {1}", userId, lastException);

// Months later, someone adds a convenience overload for the common
// "message plus one exception" case:
public static void Log(string message, Exception ex)
    => Console.WriteLine($"{message}: {ex.Message}");

// Every existing call that passed exactly one Exception as the second
// argument NOW silently binds to the new overload instead of the old
// params one - the format placeholder "{0}" is never substituted, and
// the original message text (with userId) is gone entirely.

✅ Fix: Treat a New Overload as a Binding-Compatibility Change

• Before adding a new, more specific overload to an existing method group, searching the codebase for every call site that could match its exact parameter shape is worth doing deliberately – a params overload is exactly the situation where a new sibling overload can silently reroute calls that were never touched.
• Giving the new overload a distinct name (LogException(…) instead of another Log(…) overload) removes the ambiguity entirely – it costs a slightly less elegant call site, in exchange for a guarantee that existing calls can never be silently rebound by a future addition.
• A quick regression check specifically for the params call sites (confirming the formatted output still contains the substituted values, not just that the code compiles) catches this class of bug immediately, since the compiler gives no warning at all when overload resolution shifts.

⚠️ Why the Compiler Never Complains

• This isn’t a compile error or even a warning, because from the compiler’s point of view nothing is wrong – every call still has a valid, unambiguous target method, it’s just a different one than it used to resolve to before the new overload existed.
• The bug is easiest to introduce specifically in mature, widely-used method groups (logging, formatting, validation helpers) where a params overload has quietly become the catch-all for years, precisely because those are the ones most likely to eventually get a new, more specific sibling added for convenience.