| Hi,
|
| I'm using exceptions to detect errors during construction of my apps
| document objects. And I have a try-catch block like to following to report
| errors to the user:
|
| try {
| new CDocument;
| } catch ( OSStatus error ) {
| PostError( error );
| }
|
| When testing my app, I create as many documents as possible and an
| exception occurs when the app runs out of memory - which is successfully
| caught etc.
|
| So I close all of the documents, and try to create another one - but I
| start to get some strange unmapped memory exceptions, when my document
| constructor deletes some objects as its supposed to:
| ie. CString * docMode = CopyModeFromXMLFile( file );
| if ( docMode->Is( resizableString ) ) {
| ...
| }
| delete docMode;
|
| So I'd like to know if it OK for an app to keep running after an exception
| has been caught?
Yes, it is ok.
| Any suggestions about what can cause a problem like this?
Hard to say without more code. But perhaps a couple of comments can
move the thought process along...
Unless you've overloaded new to throw an OSStatus, then you're not
catching this exception where you think you are. new throws a
std::bad_alloc. That might be causing more stack unwinding than you
have prepared for.
In general, writing exception safe code is easy to get wrong. Note
that "exception safe" doesn't necessarily mean "doesn't throw", and it
doesn't necessarily mean "rollback semantics". The basic exception
safety guarantee is simply that objects are left in a consistent and
destructible state. Herb Sutter's "Exceptional C++" has a chapter on
this subject. Anyway, it could be that the CDocument constructor (or
any number of methods not shown) is not exception safe, possibly
trashing your heap during stack unwinding.
Could be something unrelated to exceptions. Try recording the number
of documents you successfully create before the exception fires. Then
run a test that creates just that number of documents and then deletes
them (before the exception is thrown). Perhaps another part of the
code is running out of memory from a malloc or NewHandle, but failing
to gracefully handle it.
Just some places to start looking, hope this helps.
--
Howard Hinnant
Metrowerks