{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/corefx/issues/6589","repository_url":"https://api.github.com/repos/dotnet/corefx","labels_url":"https://api.github.com/repos/dotnet/corefx/issues/6589/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/corefx/issues/6589/comments","events_url":"https://api.github.com/repos/dotnet/corefx/issues/6589/events","html_url":"https://github.com/dotnet/corefx/issues/6589","id":137904815,"number":6589,"title":"Add a production assert facility","user":{"login":"GSPP","id":12032350,"avatar_url":"https://avatars.githubusercontent.com/u/12032350?v=3","gravatar_id":"","url":"https://api.github.com/users/GSPP","html_url":"https://github.com/GSPP","followers_url":"https://api.github.com/users/GSPP/followers","following_url":"https://api.github.com/users/GSPP/following{/other_user}","gists_url":"https://api.github.com/users/GSPP/gists{/gist_id}","starred_url":"https://api.github.com/users/GSPP/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GSPP/subscriptions","organizations_url":"https://api.github.com/users/GSPP/orgs","repos_url":"https://api.github.com/users/GSPP/repos","events_url":"https://api.github.com/users/GSPP/events{/privacy}","received_events_url":"https://api.github.com/users/GSPP/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2016-03-02T15:25:50Z","updated_at":"2016-03-02T22:36:56Z","closed_at":null,"body":"It is possible to use `Debug.Assert` in `DEBUG` builds to assert runtime conditions. The Base Class Library currently has no way to assert something in non-debug builds. That's a pity because in many applications it is a prudent choice to leave (cheap) assertions enabled in production.\r\n\r\nMany projects do not wish to make use of Code Contracts. It seems heavy-weight to pull in Code Contracts just to have an assert method.\r\n\r\nPlease add a release build assert to the BCL.\r\n\r\nHere are some naming proposals:\r\n\r\n```\r\nDebug.ReleaseAssert(...)\r\nAssert.Debug.IsTrue(...);\r\nAssert.Release.IsTrue(...);\r\n```\r\n\r\nAnother thing that makes `Debug.Assert` unusable in production is that it pops up a dialog box or crashes the process. This is inappropriate with ASP.NET where you normally want to simply abort the current HTTP request and let the process live. It's also inappropriate in any form of client-side GUI app.\r\n\r\nFrankly, the Abort-Retry-Cancel dialog that pops up is ... not very nice.\r\n\r\nMost apps are not overly concerned with state corruption. A `FailFast`-like approach is not desirable.\r\n\r\nTherefore, the new assert functions should merely throw an `AssertFailedException`.\r\n\r\nIf the developer chooses to add a catch-all top-level handler to his request processing then so be it. The assertion failure exception will contain the stack trace pointing to the location of the error. It will be fairly easy to debug the assertion failure from logging output.\r\n\r\nThe new assertion facility should *not* be configurable to do something else (e.g. log and `FailFast`). Developers should be able to rely on the exact exception throwing behavior outlined above. When I see a production assert in foreign code I want to know what it does. I don't want the possibility that some developer-provided hook is called.\r\n\r\nAnother benefit is that the whole ecosystem can standardize on this `AssertFailedException` class. All tools and testing frameworks can learn to understand it.\r\n\r\nThe `AssertFailedException` is useful by itself, for example to signify unreachable code:\r\n\r\n```\r\nswitch (...) {\r\n case: return 1;\r\n default: throw new AssertFailedException();\r\n}\r\n```\r\n\r\nThis would *not* be possible with `Assert(false)` because the compiler must know that all paths return a value or throw. To help with this scenario, we could as a `class UnreachableException : AssertFailedException`. Now, tools can standardize on that one as well. When Resharper generates a `switch` it can use this exception type, for example.\r\n\r\nIn this issue I have outlined the approach that I have used over 5 years in a 100 kLOC codebase. I found it to work very well."},"comment":{"url":"https://api.github.com/repos/dotnet/corefx/issues/comments/191471107","html_url":"https://github.com/dotnet/corefx/issues/6589#issuecomment-191471107","issue_url":"https://api.github.com/repos/dotnet/corefx/issues/6589","id":191471107,"user":{"login":"GSPP","id":12032350,"avatar_url":"https://avatars.githubusercontent.com/u/12032350?v=3","gravatar_id":"","url":"https://api.github.com/users/GSPP","html_url":"https://github.com/GSPP","followers_url":"https://api.github.com/users/GSPP/followers","following_url":"https://api.github.com/users/GSPP/following{/other_user}","gists_url":"https://api.github.com/users/GSPP/gists{/gist_id}","starred_url":"https://api.github.com/users/GSPP/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GSPP/subscriptions","organizations_url":"https://api.github.com/users/GSPP/orgs","repos_url":"https://api.github.com/users/GSPP/repos","events_url":"https://api.github.com/users/GSPP/events{/privacy}","received_events_url":"https://api.github.com/users/GSPP/received_events","type":"User","site_admin":false},"created_at":"2016-03-02T22:36:56Z","updated_at":"2016-03-02T22:36:56Z","body":"Thanks for bringing this to my attention.\r\n\r\n`Trace.Assert` appears to be `[Conditional(\"TRACE\")]` according to Reflector. That means it is not available in production builds. Also, if `AssertUiEnabled == false` the assert is disabled (according to your description). That doesn't help because it should be always on."}}