runtime: Improve Exception Messages

Same issue, KeyNotFoundException. When we are looking for a foo[key] in a dictionary, and it isn’t there, this is thrown. But because the key value isn’t specific, we don’t know which key that is. In many cases, just knowing the key is enough to resolve the issue.

*Hibernating Rhinos Ltd *

Oren Eini* l CEO l *Mobile: + 972-52-548-6969

Office: +972-4-622-7811 *l *Fax: +972-153-4-622-7811

On Thu, Jul 30, 2015 at 10:03 AM, Bruno Juchli notifications@github.com wrote:

There’s several places in the .net framework where exception messages can be vastly improved by providing more or the correct information. Vastly improved? Yes. It’s that cases where we need to fire up a debugger to find out what exactly has gone wrong. Now imagine the exception doesn’t occur in your code but a 3rd party library. Or even worse, it occurs when you execute some executable you aren’t even developing. It requires more and more work to acquire the necessary source, build tools etc. to actually create a debug build and then debug it. The good news is, that the need for doing so could often be eliminated by providing a better exception message. Let me pick an example

System.Security.Util.StringExpressionSet.CanonicalizePath() https://github.com/dotnet/coreclr/blob/4cf8a6b082d9bb1789facd996d8265d3908757b2/src/mscorlib/src/System/Security/Util/StringExpressionSet.cs#L751 NotSupportedException with generic message The given path’s format is not supported. https://github.com/dotnet/coreclr/blob/9501a4fac546d188c9459e79d1b77c3ca0442e49/src/mscorlib/src/mscorlib.txt#L505. The actual trigger https://github.com/dotnet/coreclr/blob/4cf8a6b082d9bb1789facd996d8265d3908757b2/src/mscorlib/src/System/Security/Util/StringExpressionSet.cs#L750 for the exception is a path containing a colon (😃 at any index > 1 (so C: is ok, :: is okay, but C: is not ok).

Now let’s pick a tool everyone knows. Nuget.exe. When you run nuget.exe pack foo.nuspec and the nuspec file contains an invalid path - what will happen? The console will show

Argument_PathFormatNotSupported

Let’s configure nuget to be more verbose by adding -Verbosity detailed. The console will now show:

System.NotSupportedException: The given path’s format is not supported. at System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Boolean needFullPath) (…) at NuGet.Program.Main(String[] args)

(yes i’ve removed part of the stack trace 😉 ). This is still not very helpful. Of course, at this point i don’t know whether the actual issue was caused by me writing an invalid .nuspec or by a bug in nuget. If the exception message would state the offending path i could check if it’s one that i wrote like this in my *.nuspec. In most cases it’ll just be that the user made a simple mistake. In all of these cases, an improved exception message would improve the user experience, as it makes it easier to find the actual mistake (there could be a lot of paths in the nuspec file).

Now that i made my case, i have a few questions for the community: How should exception messages be improved?

Alternatives (combinations thereof are valid, too)

• make the exception message more verbose
  • means there would be a lot more exception messages
  • if these are localized, this could mean substantial work
    • create custom exceptions which contain additional properties
  • should inherit from standard ones in order to not alter the interface too much
  • still a breaking change for checks like exception.GetType() == typeof(NotSupportedException (granted, checks as these should not occur too often as usually there exist better alternatives)
  • doesn’t require localization as no localizable values are involved.
  • however, would require a “consumer” of the exception to specifically evalute the property. This would diminish the benefit immensely.

Which exception messages should be improved?

I’d suggest one should start with the ones which are easy to improve. Example for something which isn’t an easy fix: NullReferenceException https://github.com/dotnet/coreclr/issues/25. What work is involved?

• Since exception messages (resources) are currently shared across multiple usages (example Argument_PathFormatNotSupported https://github.com/dotnet/coreclr/search?utf8=✓&q=Argument_PathFormatNotSupported, when creating new, more specific messages, the old inspecific ones might become superfluous. So we’d need to track if we can remove any of these.
• Specifically in regards to localization: Is there any? What’s necessary to change an exception message?

Will Pull-Requests be accepted?

As this kind of issue is not on the priority list, the question is, will any work put into this bear fruits?

— Reply to this email directly or view it on GitHub https://github.com/dotnet/coreclr/issues/1311.