Geek Answers Handbook

Assert statements in .NET production code

Is it possible to leave Trace.Assert and Debug.Assert statements in code that is “stable” and that has been ported to the testing and production environment?

If so, how do the statements state this? Is it not enough to have Guard classes, etc. Check exclusion conditions and, if necessary, make exceptions?

+4
source share
4 answers

Debug.Assert will be ignored if you do not have the DEBUG compilation constant defined, which by default occurs when compiling in the "debug" configuration, and not in the "release" configuration. Indeed, the Debug class is intended to be used only in test environments where you should catch all (or at least most) errors that could lead to a Debug.Assert error.

Trace.Assert works the same way, except that the compilation constant that must exist is TRACE, which by default exists in both "debug" and "release". It may make sense to validate the traces in the release code, but it is usually preferable to do something different than the default behavior of the method (which simply displays a message box with a trace stack). You can achieve this by setting up your own trace listener for the Trace class; see the documentation for the method for more details.

+8
source

The transition to a Prod environment is the beginning, not the end, of a program. As soon as he meets real users and the real world, you will begin to receive a lot of feedback about problems and needs that you did not expect. This means that development is only beginning. You will need your statements to help you break assumptions early on (before they create a lot of problems) and help you expand and change your program.

+4
source

One of the benefits of Assert over exception is that you may not catch the exception where the problem occurs. But Assert always happens in the right place.

+2
source

Another Assert benefit I can think of is that it helps you debug your production environment. Assertions that are still active in the release code can be captured dynamically dynamically using appropriate tools such as DbgView . It is very convenient for debugging after the release of your product.

http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

+1
source

More articles:


All Articles