I have presented a class entitled High Octane ObjectARX at Autodesk University the past two years. In 2006 the focus was on project organization, and last year I focused more on techniques for supporting multiple versions of AutoCAD with a single Visual Studio solution, touching briefly on testing and profiling. For 2008 I plan to focus on debugging.
To get you in the mood, I decided to blog about a capability of Visual Studio that often goes unnoticed and unused: breaking on an exception. This works just like breaking on a code breakpoint, except the debugger breaks execution *before* the exception handler gets control, thus allowing you to get a clearer picture of what was happening immediately before the exception occurred.
In an ObjectARX project, all kinds of exceptions can occur. Sometimes they are perfectly normal exceptions caused by and handled by AutoCAD. Many times, especially during development, your code triggers an exception that causes AutoCAD to crash, and it’s not obvious what caused things to go haywire.
When unexpected things happen while running your code under the debugger, the first order of business is to inspect the debug output window to determine what happened. The debug output window (Debug->Windows->Output) displays a message whenever an exception occurs. Sometimes a series of exceptions occur, usually all caused by the same root problem. Breaking when the first exception occurs will likely yield the most useful information about the cause.
Visual Studio contains a prepopulated list of common exceptions to choose from, or you can add new ones if you need to break on an exception that is not already listed. Many times, breaking when the exception is thrown allows you to inspect the stack trace to determine which one of your functions is to blame — and in the vast majority of cases, it will be your code that is at fault!