Are exceptions from failed dynamic binding clear enough?

[svick]

When you use dynamic incorrectly, the resulting RuntimeBinderException can be fairly confusing. Can the situation be improved?

For example, consider this code (based on code from a confused user from dotnet/docs#4487):

dynamic fileContent = 42;
new System.Net.Http.StringContent(fileContent, Encoding.UTF8, "application/base64");

This throws:

Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: The best overloaded method match for
'System.Net.Http.StringContent.StringContent(string, System.Text.Encoding, string)' has some
invalid arguments
   at CallSite.Target(Closure , CallSite , Type , Object , Encoding , String )
   at System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite site, T0
arg0, T1 arg1, T2 arg2, T3 arg3)
   at UserQuery.RunUserAuthoredQuery()

To somebody who does not know how dynamic is implemented, this exception is going to be very confusing, because:

• There is almost no indication that this exception is related to dynamic (except for the System.Dynamic namespace in the stack trace).
• There is no indication regarding which arguments are invalid.
• Nitpick: The error message talks about overloaded method, when it's actually a constructor.

Since the exception type can't really be changed because of backwards compatibility, that leaves the exception message. Maybe it could be changed to something like the following?

Error in dynamic binding: The best overloaded constructor match for 'System.Net.Http.StringContent.StringContent(string, System.Text.Encoding, string)' has some invalid arguments:
Argument 1: cannot convert from 'int' to 'string'

Do you agree that this is something that should be improved? Is changing the error message to something like the above the way to go?

[JonHanna]

I think in this particular case it's because CS1503 is only ever raised after CS1502 or CS1594. In static compilation the CS1503 is then prioritised, but if you are throwing exceptions rather than displaying error messages once you've thrown an exception you aren't processing any more and CS1502 is all that you get. Indeed, I removed the code for reporting CS1503 precisely because it can never be reached.

If you thought CS1503 was preferable we could undo some of the changes in dotnet/corefx#22748 so that it would throw that rather than CS1502, but personally I think CS1502 is preferable in the cases where one could get multiple CS1503s:

public static void Method(string x, string y)
{
}

/*…*/
Method(a, b);

If a and b were both int then in static compilation we'd get both "CS1503 Argument 1: cannot convert from 'int' to 'string'" and "CS1503 Argument 2: cannot convert from 'int' to 'string'". If they were both dynamic containing int then I think that "The best overloaded method match for 'Method(string, string)' has some invalid arguments" is a better description in one error that there was one or more mis-matches (in this case two) than reporting just one.

[JonHanna]

(That said, there are also cases where error messages are just plain wrong, which I'm much more eager to change).

[svick]

How hard would it be to report both error messages (or all three, in your example)?

[JonHanna]

It wouldn't be terribly hard, but really long error messages have their own downside.

One thing I've mused about a bit is including error codes in RuntimeBinderException. The majority (but not all) causes of it relate to a C# compiler error and being able to lookup CS1052 would give one a lot more detail than can fit in an error message. I had thought (and even submitted a PR but then thought better of it) of using the HelpLink property but .NET documentation hasn't generally had "cool" URIs in the past, so it could be obsolescence waiting to happen. Just having the code available as a property could help if an error was mysterious.

[svick]

.NET documentation hasn't generally had "cool" URIs in the past

In case it's useful, currently the URLs are e.g. https://docs.microsoft.com/dotnet/csharp/language-reference/compiler-messages/cs1502. I think that URL should be alive for a long time. Though not all errors have such URL (e.g. CS1503 doesn't have it, the only documentation for that one is the hidden https://docs.microsoft.com/dotnet/csharp/misc/cs1503).

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.