VS 2003 Tip #3: View exception information with $exception

Every now and then a feature gets put into the product that just gives you this tickle of excitement every time you think about it. $exception I find is one of those features.

Ok - so what scenario would I use it in? Lets say you're writing some managed code. You're debugging your merry way through the code when voilà, it crashes. Sigh. You see the little error dialog with additional information but to explore your code you have to dismiss it. As you go through your code, you wonder what that message said again? So you write a try catch and repeat the process.

Well, in Everett the debugger team put in a little feature called $exception. The next time you crash in C# or J# go ahead and dismiss the dialog. Open the locals window and take a peek at $exception there (chills are setting in right now). Expand it and you can see all the delightful things inside the Exception object - Messages, Stacktrace, Inner Exception etc - everything you would have gotten had you put a try catch around the code and caught the exception object. Is that cool or what?

Comments

• Anonymous
  February 20, 2004
  VB does not seems to have $Exception...
• Anonymous
  February 20, 2004
  VB doesn't seem to have very much but skipping right along....quickly shuffles crowd onwards...
• Anonymous
  February 20, 2004
  Sweet!!!!
• Anonymous
  February 23, 2004
  This is cool but why aren't you catching the exception in the first place?
  
  Personally, I just wrap everything in a try, call a central exception handler, and while developing put a breakpoint in the handler...
• Anonymous
  March 01, 2004
  Quick! Everyone copy Dennis - his is the only way. (apparently)
• Anonymous
  March 02, 2004
  Oh, gimme a break, im...didn't say it was the only way, just another way, which I happen to use...my question wasn't rhetorical.
• Anonymous
  March 02, 2004
  "This is cool but why aren't you catching the exception in the first place?"
  
  Because you want to allow the exception to bubble up the call stack? Often the immediate (or a not-so-immediate) caller of a method will have much better information about the context of an exception than the actual site where the exception was thrown. In those cases there's no point to adding a try...catch block since the catch would just be rethrowing the exception without adding any real value. You might as well bubble the exception up and see if the next higher caller can add any information.
  
  Obviously at the top level you probably want to catch the exception whether you can add any value or not, so that you can log it and display a pretty message to the user (if there is a UI).
• Anonymous
  March 03, 2004
  The comment has been removed
• Anonymous
  March 03, 2004
  The comment has been removed
• Anonymous
  March 03, 2004
  Hmmm - I often go to the Debug-Exceptions dialog and just turn on "break into the debugger" for all CLR exceptions. Yes, you occasionally get first chance exceptions that you can just let go by, but it works quite well generally speaking.
• Anonymous
  March 20, 2004
  I've flip-flopped back and forth between VB and C based languaged, and finally ended up in the lap of vb.net after writing ASP pages for quite some time in vbscript, and am just wondering why C# has so many more useful features than VB. We know that they all compile down to MSIL, but still, there are many more useful things in C# than in VB.Net and I can't help but feel left out. I love VB, and don't want to give it up. Just a thought.