From the NewsFeed on my CAD/Court web site:
“The court today issued an order denying Autodesk’s motion to dismiss the charges in the Vernor lawsuit. Normally such a denial is perfunctory and mundane, but in this ruling the court performs a breathtaking analysis of whether the AutoCAD software was a sale or a license, and reaches conclusions that, if not reversed, are certain to change the face of software sales in the USA. Technically, the scope of this order is limited to simply refusing to grant Autodesk’s motion to dismiss the lawsuit, but the implications of the judge’s analysis are almost stunning in their rejection of Autodesk’s legal claims. I’m sure you will be hearing much more about this order in the coming weeks, as the entire software industry will certainly take notice of this case.”
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.
Once you examine the debug output window to determine the type of exception that occurred, open the Exceptions dialog (Debug->Exceptions) and tell Visual Studio to break when the exception is thrown:
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!