Can't catch C++ exception

I have a case where I cannot catch exceptions generated by CRecordset::MoveNext().  Other exceptions are caught by my exception handler (catch block), but this one results in only the following message appearing in the Output window of the debugger.

First-chance exception in ... Microsoft C++ Exception.

Then control returns to the statement following the MoveNext() that caused the exception.  What might be going on?  Do you have any suggestions for debugging this problem?  Are we looking at possible stack corruption?

Thank you,
Bruce O'Reilly and Andre Nguyen
boreillyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

gelbertCommented:
When you are in debug mode in VC++ 5.0 go to menu item "debug" subiten "Exeptions". Select all listed type of exceptions and change status to "Stop Always". It make debugger stop when exceptions arise instead of displaying message in output window
0
boreillyAuthor Commented:
I have already tried what Gelbert suggested.  Using that, I see the exception being raised deep down in the ODBC DLL after CRecordSet::FetchData() calls ::SQLExtendedFetch().  The problem is, what could cause the exception to be uncatchable by my handler?
0
alexoCommented:
The exception raised is not really a C++ exception.  Check the help about SEH (structured exception handling) and how to catch such exceptions in C++.
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

yonatCommented:
Maybe the exception is caught BEFORE it reaches your catch clause.

BTW, catch(...) catches all exceotions, including the structured exceptions that alexo mentioned.
0
mikeblasCommented:
The behaviour you note is entirely by-design and completely normal.

You're calling into some other functions. Those functions probably call other functions, too. When the exception is raised, the environment tries to find an exception handler. It searches by looking at the current function, the function that called it, the function that called that one, and so on--unwinding the stack of function calls.

You're not hitting your own catch() block because some other catch() block is handling the exception, and that's that. The message from the debugger is entirely normal: when an exception is thrown in a process that is being debugged, the debugger is notified _immediately_. The debugger can stop execution before the environment tries to find a handler, or it can let the thread that's throwing the exception try to find a handler.

Since the author of the ODBC driver you're using knew that an exception might happen, they wrote a catch() handler of their own to manage the execption. The exception is thrown and you see the message in the debugger. But the environment ends up finding the catch() handler the driver itself implements and executes that handler. The handler doesn't rethrow the exception, so processing continues on as normal. And that's that: you're not offered a chance to catch() the exception because someone else closer to the exception has already handled it. Even if you got the chance to handle the exception, you wouldn't know what to do: you don't have the source code for the driver, and the throw structure that the driver uses internally aren't documented.

If you've set the "Exceptions" option that GELBERT talks about to "Stop Always", the debugger will immediately break when the exception is thrown. That can help you debug the code generating the exception or the code which is going to find the exception handler.  Otherwise, if that option isn't set for the type of exception being generated, the debugger returns control immediately to the thread that threw the exception so it can search for a handler.

That's why a "first-chance exception" has it's name: the debugger is offered the first chance at handling a rasied exception. The message is just informational. If there is no debugger attached to the process, the thread will immediately begin search for a handler. If a handler is found, it executes. If no handlers is found, the operating system kicks the process out of memory with an "unhandled execption" error.

You can find lots of information about the mechanism at work here by reading.  See the KB article Q105675, for example, for a description of the messages the debugger generates.  Or, read up on the "Exception Handling" topics in the SDK--like "Exception Handling for Debugging".  Or, read the "Understanding the Debugger" article I wrote for Visual C++ Developer; see http://www.pinpub.com/vcd/home.htm for more information about that magazine.

The exception raised is _certainly_ a C++ exception; if it wasn't, it wouldn't have the "Microsoft C++ exception" type ID. An systems exception has a type ID describing the exact error that ocurred.

A catch(...) block will catch all thrown exception types that are scoped for it--it still won't catch exceptions of _any_ type that are handled by more deeply scoped catch() handlers.

.B ekiM

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
boreillyAuthor Commented:
Mike,
Thank you very much for the help.  What threw me off is that I could not find the exception handler when tracing this with the debugger, but that's not too surprising given that I don't have source to the Access '97 ODBC driver.  Your book is really great.  Every MFC programmer in this place owns an copy and we all use it regularly.  We just call it "Mike's book".

Bruce O'Reilly
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.