Shouldn't missing format string parameters be a compile-time error?

Question

In cases where the full text of the format string is static and known at compile time, shouldn't a missing format string parameter be a compile-time error or, at the very least, warning?

ReSharper catches this, but it's just an underlined squiggle. I was under the impression that this would trigger a general compile-time error:

string x = string.Format("soeuotnh {0}");

Is there any way to trigger a warning on this kind of error without having to run my code through FxCop or something? Even C/C++ compilers will trigger an warning/error for such a blatantly clear bug (though they generally won't check type-safety).

Answer 1

It could be a warning, but should it be? Well, that's up to the compiler team I suppose, it's not like String.Format is a part of the C# language.

This isn't C; you're not invoking undefined behavior or anything, the method can simply deal with the missing parameter and the assumption is (I assume...) that you will catch it pretty quickly when it throws an exception. There's nothing "dangerous" about it, it's just a logic error.

Answer 2

I don't think there is any way other than what you mentioned for detecting this condition automatically. As to why this happens, the Format method is matching against the (String, params Object[]) overload, which the parameters are defined in the documentation as this:

public static string Format(
    string format,
    params Object[] args
)

format Type: System.String
A composite format string (see Remarks).

args Type: System.Object[] An object array that contains zero or more objects to format.

Since the params defines a variable number of arguments (including zero arguments), that is why there is no compile-time exception thrown.

Edit:

Since there is a valid overload for the compiler to select, then you won't get a compile-time error. So this ceases to become a compiler issue, and your best bet is to use Resharper, which is a code quality tool, to detect this condition.

Answer 3

Some C compilers will parse format strings because having format strings that don't match the parameters can cause serious crashing bugs -- or even worse, security bugs. In C#, though, you just get an exception at the call site, so it's not critical.

The compiler could do it, but that would require code to recognize string.Format as a special case, and (even worse) would need somebody to write a format string parser in the C# compiler. All so that it can warn you about code that will crash every time it's executed.

The big problem with this is that many people compile with all warnings on and warnings as errors, meaning that adding this warning will break their build. Anybody with some bad format string in a dark corner of their code where it's never executed will suddenly be unable to build their product. These people will complain.

Answer 4

As has already been said, this isn't something the compiler does or should worry about.

How would you expect the compiler to behave when doing something like:

string format = "{0}";
List<string> parms = new List<string> { "Hello" };

if (DateTime.Now.Second % 2 == 0)
{
    format += " {1}";
    parms.Add("World");
}

Console.WriteLine(format, parms.ToArray());

Answer 5

Resharper shows warning for this case: "Non-existing argument in formatting string".

Answer 6

The "format" parameter of the method is not constant. Everything that is not constant can not be checked at compile-time.

It can be composed at run-time via various methods, it can even be user-input... (The horror!)

That's why it is not a compile-time error.

Edit: OK, In the case that it is a constant expression it could be analyzed and a warning could be generated. But here is the answer from Eric Lipert on a different question a bit aplicable: There's a bar of benefit over cost.

Whether this is a real benefit that is worth spending the special case scenarios for String.Format (and possibly other string format functions) is... a tough call.

Answer 7

I have filed a request for consideration of this feature on Microsoft Connect, as I feel that

• The answers saying "people would prefer their code compile and fail at runtime if it's a not very hot codepath" is just absurd and has no place in non-interpreted languages, and especially not explicitly-defined, strongly-typed languages that place such an importance on type safety as C#.
• The answers saying the compiler is physically not capable of (ever) deducing the format string and the parameters array at compile time are also incorrect. Yes, there are times when the compiler cannot deduce one or the other (or both) at compile time, and there's nothing that can be done about those, but many other times, it has the full info at its disposal.
• The answers saying this is outright not the compiler's job just because the spec doesn't mention throwing a warning for this kind of behavior are missing the fact that the spec is the minimum that a compiler should implement, and the compiler is free (and does indeed to a great, great extent) to go above and beyond so long as it's not in conflict with the spec.
• The answers saying C compilers don't do this either are plain wrong - I have posted examples otherwise.
• The answers saying the code sample I posted does not throw an exception at runtime are blatantly wrong (though most have been edited since then).

At the end of the day, it's a "yes it could, no it doesn't, maybe it should" situation. I was trying to make sure that there wasn't something I could set in the compiler (not third party software) to make it more agressive with its warnings or if there were some way I could change my code to make it throw an exception (for instance, declaring everything as const), but it turns out (thus far) that that is not possible. Regardless of the response of the Visual Studio team on the issue I opened on MS Connect, the fact remains that the compiler certainly can catch a great many string formatting exceptions at compile time, that it would be a benefit... but it remains for the VS team to determine whether or not it is something worth implementing.