views:

169

answers:

5

I was getting bad data from an application I was writting using C++ in Visual Studio 2k3 so I decided to debug it. Then I found it was throwing an exception but one I can't track down.

Then I placed some try/catch blocks and low and behold, when I don't debug there is no exception. That is, I have code that looks like this:

std::vector<MyClass*> ListOfStuff;
.
.
.
try
{
.
.
.
   const MyClass * localPointer = ListOfStuff[i]; //This is where the exception occurs
.
.
}
 catch (...)
{
   int x = 0;  //place break here
}
So if I step through the code line by line I'll get an exception and shot to the catch. But if I just let it run with a breakpoint inside the catch nothing happens. Using an iterator has the same behavior. And I can successfully check the size of the vector so I know I'm within the bounds.
Can anyone tell me what's going on? If it matters I'm using some standard windows libraries and openGL.

+1  A: 

Is the exception an ASSERT? These may get compiled out at compile time or otherwise throw an assertion.

For example, you could have

#ifdef DEBUG
#define ASSERT(cond) if (cond) throw CDebugAssertionObj;
#else
#define ASSERT(cond)
#endif
Doug T.
A: 

If you're using a good IDE that allows conditional breakpoints (such as, "break here if i == 5"), then it's possible the condition itself is causing the exception.

Had that one for while... my head hurt when I found it.

Bill James
+1  A: 

You can try placing a

DebugBreak();

call in the catch clause. If the app is running in the debugger, it should get control. If it's not running in the debugger you should get an opportunity to attach the "Just in Time" debugger (which is usually Visual Studio if you have that installed).

Michael Burr
+1  A: 

I'm referring to VS2005 but it should be applicable in your case. If you access the IDE Debug > Exceptions.. menu item you can specify the exception types that the IDE debugger should break on when thrown which should cause you to see the line the exception was raised by when single stepping through the application.

You may need to play around with what types to catch (some 1st chance exceptions are not actually problems) but it will be helpful in identifying the point the exception is raised.

Henk
A: 

Is that code part of a class method, and is ListOfStuff a member of the class? If so, check to make sure that your this pointer is valid.

Adam Rosenfield