assertions

I am getting this error message: Debug Assertion Failed! Expression:_BLOCK_TYPE_US_VALID(pHead->nBlockUse) while trying to do the following #include <vector> #include <algorithm> using namespace std; class NN { public: NN(const int numLayers,const int *lSz,const int AFT,const int OAF,const double initWtMag,const int UEW,const double *extInitWt); double sse; bool operator < (const NN &net) const {return sse < net.sse;} }; class Pop { int popSize; double a; public: Pop(const int numLayers,const int *lSz,const int AFT,const int OAF,const double initWtMag,const int numNets,const double alpha);

How do I use Assert.Throws to assert the type of the exception and the actual message wording. Something like this: Assert.Throws<Exception>( ()=>user.MakeUserActive()).WithMessage("Actual exception message") The method I am testing throws multiple messages of the same type, with different messages, and I need a way to test that the correct message is thrown depending on the context. Patrik Hägne Assert.Throws returns the exception that's thrown which lets you assert on the exception. var ex = Assert.Throws<Exception>(() => user.MakeUserActive()); Assert.That(ex.Message, Is.EqualTo("Actual

I've written an assertion method Ensure.CurrentlyOnUiThread() , below, that checks that the current thread is a UI thread. Is this going to be reliable in detecting the Winforms UI thread? Our app is mixed WPF and Winforms, how best to detect a valid WPF UI thread? Is there a better way to do this? Perhaps code contracts? Ensure.cs using System.Diagnostics; using System.Windows.Forms; public static class Ensure { [Conditional("DEBUG")] public static void CurrentlyOnUiThread() { if (!Application.MessageLoop) { throw new ThreadStateException("Assertion failed: not on the UI thread"); } } } Don't

I've been a professional software engineer for about a year now, having graduated with a CS degree. I've known about assertions for a while in C++ and C, but had no idea they existed in C# and .NET at all until recently. Our production code contains no asserts whatsoever and my question is this... Should I begin using Asserts in our production code? And if so, When is its use most appropriate? Would it make more sense to do Debug.Assert(val != null); or if ( val == null ) throw new exception(); In Debugging Microsoft .NET 2.0 Applications John Robbins has a big section on assertions. His main

Today I saw a JUnit test case with a java assertion instead of the JUnit assertions—Are there significant advantages or disadvantages to prefer one over the other? Yishai In JUnit4 the exception (actually Error) thrown by a JUnit assert is the same as the error thrown by the java assert keyword (AssertionError), so it is exactly the same as assertTrue and other than the stack trace you couldn't tell the difference. That being said, asserts have to run with a special flag in the JVM, causing many tests to appear to pass just because someone forgot to configure the system with that flag when the