Debugging and Exception Handling

Suppose you have the following code:

When running the program, the following window is popped up:


When running it in the debugger, a different window is popped up:


and the debugger takes you to the line of code that threw the exception. Looking into the output window, you can see something like this:

First-chance exception at 0x7c812a5b in win32test.exe: Microsoft C++ exception: std::runtime_error at memory location 0x0012fd70..
Unhandled exception at 0x7c812a5b in win32test.exe: Microsoft C++ exception: std::runtime_error at memory location 0x0012fd70..

It shows a first-chance and an unhandle (also knows as second-chance) exception message. When running a program in debugger, the debugger always sees the exception before the program does. Thus, it is said that the debugger gets a first chance to handle the exception. If it does not do that, and the execution continues, the program will see the exception and has a chance to handle it. If the exception is not handled by the program, the debugger gets a second-chance to see the unhandled exception. This is the point when in the absense of the debugger, the program crashes.

So, what happened with the program above: the debugger saw an exception and printed the first-chance exception message, but did not handle it, and the program was allowed to continue. However, the program did not handle the exception either, and the debugger got its second-chance with the unhandled-exception; the unhandle exception messages was printed and the exception windows was popped.

Of course, you could change to code in function main to this:

In this case when run, the program will not crash. But when running in the debugger, you will see the first-chance exception message:

First-chance exception at 0x7c812a5b in win32test.exe: Microsoft C++ exception: std::runtime_error at memory location 0x0012fd5c..

In this case, the program handled the exception (by doing nothing) and the debugger did not get the second-chance.

Now, suppose your program is much langer than the several lines of code shown above. When running in the debugger you see first-chance exception messages, but not the second-chance exception message, because your program handles the exception. Should you investigate the cause of the exception, problems arise simply because you don’t know where the exception was thrown. The good news is that you can customize the debugger to break on first-chance exception.

From the Debug menu, use the Exceptions command to open the dialog that allows you to specify on which exception should the debugger break.

There are several categories:

  • C++ exceptions
  • Common Language Runtime Exceptions
  • Managed Debugging Assistants
  • Native Run-Time Checks
  • Win32 Exceptions

By default, none of the C++ exceptions is checked. That means if you check std::exception (as shown in the picture), the debugger should stop when and exception of a type derived from std::exception is thrown. (To verify that run the code aboe in the debugger again.)

What if std::runtime_exception was replaced with a custom exception, foo_exception?

Of course, the debugger would not stop when having the first-exception to handle it, because foo_exception is not in its list. You can however, change than by adding foo_exception to the list from the Exceptions dialog (as shown below) and check it for breaking on first-chance.

Running again would stop the debugger when foo_exception is thrown.

1 Comment on "Debugging and Exception Handling"

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.