You can use the reserved keyword $exception in the object inspector to get details of any caught exception.
I’d forgotten about this one. Found it when reading about other tricks for tracking down exceptions
You can use the reserved keyword $exception in the object inspector to get details of any caught exception.
I’d forgotten about this one. Found it when reading about other tricks for tracking down exceptions
I was writing a mock test yesterday which had some explicit expectations about the number of times a particular member would get called.
This seemed all too weird at the time. There was nothing different in either case which should cause this problem. The only clue I had was the fact that when running within the debugger, I was getting unexpected results, and when running independently of the debugger, it worked as expected. This lead to the conclusion that the problem is caused by debugging the test. Ie: The act of observing my test run, is changing the test execution itself. Also known as the Observer Principle.
The answer to the problem is far less exciting. I realised after a few minutes of tinkering that I had some of the mocked member fields hooked into my Watch window. So upon each step and execution, the Watch was re-evaluating my members which in turn was eating up my predefined expectations!
It totally makes sense when you realise what’s going on, but until that point this problem exhibits itself in a very weird way…
[UPDATE]
I’ve since discovered that this sort of bug (which changes itself while you probe it) is also known as a Heisenbug
Stumbled across a VS.NET power tweak
<ctrl> + ]
Found this article on DNK consisting of shortcuts for Visual Studio.
Recording it here for future reference….i always keep forgetting
short post…..
In some cases, the .NET framework will throw an exception internally, and then (using it’s own exception handling routines) re-throw something else based on that exception. if you’re getting an exception thrown from the Framework which you don’t really understand, and can’t work out what is causing the problem, try turning on the First Chance Exception for the .NET CLR in VS (Debug –> Exceptions).
This allows VS to catch any CLR exceptions when they are thrown, and will give you more insight into what’s the root cause of the problem.
Also, make sure you turn it off when you’re done otherwise you could end up constantly chasing your tail catching unnecessary exceptions