{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/coreclr/issues/1311","labels_url":"https://api.github.com/repos/dotnet/coreclr/issues/1311/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/coreclr/issues/1311/comments","events_url":"https://api.github.com/repos/dotnet/coreclr/issues/1311/events","html_url":"https://github.com/dotnet/coreclr/issues/1311","id":98099898,"number":1311,"title":"Improve Exception Messages","user":{"login":"BrunoJuchli","id":2090172,"avatar_url":"https://avatars.githubusercontent.com/u/2090172?v=3","gravatar_id":"","url":"https://api.github.com/users/BrunoJuchli","html_url":"https://github.com/BrunoJuchli","followers_url":"https://api.github.com/users/BrunoJuchli/followers","following_url":"https://api.github.com/users/BrunoJuchli/following{/other_user}","gists_url":"https://api.github.com/users/BrunoJuchli/gists{/gist_id}","starred_url":"https://api.github.com/users/BrunoJuchli/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BrunoJuchli/subscriptions","organizations_url":"https://api.github.com/users/BrunoJuchli/orgs","repos_url":"https://api.github.com/users/BrunoJuchli/repos","events_url":"https://api.github.com/users/BrunoJuchli/events{/privacy}","received_events_url":"https://api.github.com/users/BrunoJuchli/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":25,"created_at":"2015-07-30T07:03:05Z","updated_at":"2015-07-31T17:26:09Z","closed_at":null,"body":"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.\r\nThe good news is, that the need for doing so could often be eliminated by providing a better exception message.\r\n\r\nLet me pick an example\r\n--------\r\n[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).\r\n\r\nNow let's pick a tool everyone knows. Nuget.exe.\r\nWhen you run `nuget.exe pack foo.nuspec` and the nuspec file contains an invalid path - what will happen?\r\nThe console will show\r\n\r\n> Argument_PathFormatNotSupported\r\n\r\nLet's configure nuget to be more verbose by adding `-Verbosity detailed`. The console will now show:\r\n>System.NotSupportedException: The given path's format is not supported.\r\n   at System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Boolean needFullPath)\r\n  (...)\r\n   at NuGet.Program.Main(String[] args)\r\n\r\n(yes i've removed part of the stack trace ;-) ).\r\nThis 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).\r\n\r\nNow that i made my case, i have a few questions for the community:\r\n\r\nHow should exception messages be improved?\r\n----\r\nAlternatives (combinations thereof are valid, too)\r\n - make the exception message more verbose\r\n  - means there would be a lot more exception messages\r\n  - if these are localized, this could mean substantial work\r\n - create custom exceptions which contain additional properties\r\n  - should inherit from standard ones in order to not alter the interface too much\r\n   - 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)\r\n   - doesn't require localization as no localizable values are involved.\r\n   - however, would require a \"consumer\" of the exception to specifically evalute the property. This would diminish the benefit immensely.\r\n\r\nWhich exception messages should be improved?\r\n----\r\nI'd suggest one should start with the ones which are easy to improve. Example for an exception which isn't easy to improve: `NullReferenceException` - see #25\r\n\r\nWhat work is involved?\r\n-----\r\n - Since exception messages (resources) are currently shared across multiple usages (example [Argument_PathFormatNotSupported](https://github.com/dotnet/coreclr/search?utf8=%E2%9C%93&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.\r\n - Specifically in regards to localization: Is there any? What's necessary to change an exception message?\r\n\r\nWill Pull-Requests be accepted?\r\n------\r\nAs this kind of issue is not on the priority list, the question is, will any work put into this bear fruits?"},"comment":{"url":"https://api.github.com/repos/dotnet/coreclr/issues/comments/126759424","html_url":"https://github.com/dotnet/coreclr/issues/1311#issuecomment-126759424","issue_url":"https://api.github.com/repos/dotnet/coreclr/issues/1311","id":126759424,"user":{"login":"OtherCrashOverride","id":3499273,"avatar_url":"https://avatars.githubusercontent.com/u/3499273?v=3","gravatar_id":"","url":"https://api.github.com/users/OtherCrashOverride","html_url":"https://github.com/OtherCrashOverride","followers_url":"https://api.github.com/users/OtherCrashOverride/followers","following_url":"https://api.github.com/users/OtherCrashOverride/following{/other_user}","gists_url":"https://api.github.com/users/OtherCrashOverride/gists{/gist_id}","starred_url":"https://api.github.com/users/OtherCrashOverride/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/OtherCrashOverride/subscriptions","organizations_url":"https://api.github.com/users/OtherCrashOverride/orgs","repos_url":"https://api.github.com/users/OtherCrashOverride/repos","events_url":"https://api.github.com/users/OtherCrashOverride/events{/privacy}","received_events_url":"https://api.github.com/users/OtherCrashOverride/received_events","type":"User","site_admin":false},"created_at":"2015-07-31T17:26:09Z","updated_at":"2015-07-31T17:26:09Z","body":"There are many that do not want information leaked in exceptions.  I don't accept the \"its not a security risk\" argument at all.  How long until a key called \"; DROP TABLES *;\" ends up in an exception that gets written to your SQL log?\r\n"}}