Re: Exception handling?

On Jun 22, 5:17 pm, "RB" <NoMail@NoSpam> wrote:
   Additionally I have this logic going so far.
// in the read loop of MyDoc class serialize
        ar >> FID_Read;;      //  DWORD FID_Read;          
        if (FID_Read != FileID)  // const DWORD FileID;
          { // FileID mismatch
            throw new CWrongFileIDException();  
        ar >> VerData.Ver >> VerData.CpyRt >> VerData.Corp;
     catch(CWrongFileIDException* e)    
        // Do whatever I may need here
        // so far nothing that I can tell, in fact it seems I could have just
       // eliminated my try and catch handlers and just called the
      //  AfxThrowArchiveException in the if loop above ?
        e->Delete( );
        AfxThrowArchiveException(CArchiveException::badIndex, NULL ); //Invalid file format
// The above takes me to the exact same cleanup code that I get when
// I read in a corrupt file (with NO exception code at all ) and mfc handlers it.
// And leaves me with an untitled filename eliminating the change if inadvertant
// save overwrite.

As I said: you are not permitted to write try/catch statements ;-)

In this case (wrong "magic" in the file), you have these options

1. use AfxThrowArchiveException with e.g. badIndex (kinda silly name
given the associated message, but fair enough).

2. (consequence of the ReportSaveLoadException catch I spoke before)
derive your own exception class with whatever info you want, and
override ReportSaveLoadException to handle it. You need to override
it, because ReportSaveLoadException handles only "archive" and "file"
exceptions (doc says it handles "typically a CFileException or
CArchiveException", but it in fact handles these in a more precise
ways, and for the rest it pops up "generic" message, so you might want
to improve on that.

But I'd say that 1 is just fine. At any rate, biggest chance of that
happening is that somebody is jerking up the file intentionally. Do
you want to help these people too much? ;-)