At work this week, I noticed and then learned a couple of things that I hadn’t realised before.
We are doing some work on making our in-process COM component report errors back to us when something goes wrong. We use structured exception handling to catch all errors. The handler can capture a stack trace and send it back to us by passing it back to a managed .NET application which sends the error back using some existing technology ( SmartAssembly ). What surprised me was that when we continued a deliberately faulting application in the debugger, the application seemed to be stuck on the line that raises the error.
I eventually simplified an example of this behaviour to a standalone piece of C++ that looks like this:
If you continue in Visual Studio after the exception is trapped, you get the same exception raised again. Single stepping into the code that that is invoked, you can see that the system checks for a debugger being attached, and then deliberately choses to restart on the problem instruction. Without a debugger, it drops through to the usual uncaught exception handler which potentially dumps the process memory. Thinking about it, this behaviour is good, as if you accidentally continue in the debugger, you do not loose your error state. I’m not sure I’d noticed this behaviour in the past though.
While writing some code that dealt with byte arrays, I also came across the following behaviour.
It is initially surprising that result1 is –1, compared to result2 being 0 ie zero isn’t a member of the byte array. To understand why, hover the mouse in Visual Studio over the call to IndexOf.