apd.htm

VC 21天 学习VC 的好东西

<B>FREEING SYSTEM RESOURCES</B></P>

	<P>This exception-catching principle becomes very useful when you want to detect
	and handle errors arising from large portions of code. It can save coding lots of
	individual error-checking lines, but you must still free up any system resources
	that you've allocated in lines before the exception was raised.
<HR>


</BLOCKQUOTE>

<H3><A NAME="Heading3"></A>Throwing Exceptions</H3>
<P>You can throw exceptions yourself from code embedded in any enclosing try block
when an error condition arises. The corresponding catch block will then handle the
exception. Or you can throw the exception again from within a catch section to a
higher-level catch section, enclosing the first.</P>
<P>Several AfxThrow... functions will automatically generate and throw various types
of MFC exceptions up to the next catch level, such as AfxThrowFileException() or
AfxThrowMemoryException(). These are covered in detail in the &quot;MFC Exception
Types&quot; section. However, these functions create a new instance of a specific
CException-derived object for you--using the C++ new<I> </I>keyword and then the
throw keyword to raise an exception, as shown in the code fragment in Listing D.5.</P>
<P>
<H4>LISTING D.5.&nbsp;LST29_5.CPP--RAISING AN EXCEPTION WITH THE throw KEYWORD.</H4>
<PRE>1: try
2: {
3:     DoSomeFileHandling();
4: }
5: catch(CFileException* e)
6: {
7:     e-&gt;ReportError();
8:     e-&gt;Delete();
9: }
10: 
11: return TRUE;
12: }
13: 
14: BOOL bSomeThingWentWrong = TRUE;
15: 
16: void CExceptionalDlg::DoSomeFileHandling()
17: {
18:     // ** ... File handling functions
19:     if (bSomeThingWentWrong == TRUE)
20:     {
21:         CFileException* pException = 
22:            new CFileException(CFileException::generic);
23:         throw(pException);
24:     }
25: 
26: // ** ... Yet More file handling
27: } 
</PRE>
<P>In Listing D.5 the try block encloses a call to the DoSomeFileHandling() function
in line 16. This function may implement some file-handling procedures and raises
an exception when the error condition on line 19 is found to be TRUE. Line 22 creates
a new CFileException object passing the CFileException::generic flag to its constructor
and then throws the new object in line 23 to be caught by the catch section in line
5.</P>
<P>This process of newing a CException-derived object and then using the throw keyword
is the basis of the exception-raising mechanism. The specific details indicating
the cause of the error can be attached to the CException object, or extra information
can be added by deriving a class from the CException base class and adding extra
variables to store more specific information.</P>
<P>Your catch block can then determine whether the error is too severe to be handled
at that level. If so, you might want to throw the exception out to a higher-level
enclosing catch block. You can use the throw keyword (with no parameters) from within
the catch block to rethrow the exception before you delete it. Instead of deleting
the exception, you could rethrow it to a higher level catch block by changing the
catch block shown in Listing D.5 to add the throw keyword like this:</P>
<P>
<PRE>e-&gt;ReportError();
throw;
</PRE>
<P>Then after reporting the error, the exception will be thrown again for an enclosing
try block to catch. If you haven't implemented this nesting, the overall MFC outside
the catch block will catch it. You can use this nesting mechanism to determine the
error severity and implement appropriate recovery mechanisms at various hierarchical
levels in your program.</P>
<P>
<H3><A NAME="Heading4"></A>Deleting Exceptions</H3>
<P>As you've seen, you are fundamentally responsible for new-ing exceptions and must
also delete these objects when you've handled them. If you delete one of the MFC
exceptions, you shouldn't use the normal C++ delete keyword (as you've seen) because
the exception might be a global object or a heap object. Instead, the CException
base class has a Delete() function that first checks to see whether the exception
should be deleted. The creator of the exception can specify whether the exception
should be deleted or not by passing TRUE into the b_AutoDelete parameter of the CException
class's constructor (which is the only parameter).</P>
<P>
<H2><A NAME="Heading5"></A>MFC Exception Types</H2>
<P>The Microsoft Foundation Classes have several predefined CException-derived classes
that are used during different types of MFC operations. You've already seen CFileException
and CResourceException in use. The following section covers each of these various
classes and how it is raised in more detail. Each class is based on the CException
class and extends the functionality of CException for different types of exception
handling. You can also derive your own exception classes from CException, and a generic
CUserException is used for user-oriented application exceptions.</P>
<P>
<H3><A NAME="Heading6"></A>Using the CException Base Class</H3>
<P>CException itself has a constructor that takes an AutoDelete flag as discussed
earlier, and is defined like this:</P>
<P>
<PRE>CException( BOOL b_AutoDelete );
</PRE>
<P>If you new a CException or derived class, you should ensure that this is set to
TRUE so that it will be deleted with the C++ delete keyword. Otherwise, a global
or stack-based exception should pass TRUE so that it is deleted only when it goes
out of scope (at the end of a function or program that declares it).</P>
<P>The base class contains the Delete()function and two error-reporting functions.
GetErrorMessage() can be used to store the error message into a predefined buffer
and specify the ID of a help message to show the user context-specific help pertinent
to the error. Its first parameter is the address of a destination buffer to hold
the associated error message. The second parameter specifies the maximum size of
the buffer so that messages stored in the buffer don't over-spill outside the buffer
area. The third optional parameter can specify the context help ID as a UINT value.</P>
<P>You might use this function to help format an error message more relevant to your
application:</P>
<P>
<PRE>char msg[512];
e-&gt;GetErrorMessage(msg,sizeof(msg));
CString strMsg;
strMsg.Format(&quot;The following error occurred in 
&Acirc;MyApp: %s&quot;,msg);
AfxMessageBox(strMsg);
</PRE>
<P>The sizeof() C++ operator in the GetErrorMessage() function returns the size of
an array or variable, so if the msg array is changed, you don't have to change any
other code. The message is then formatted into the strMsg CString object and displayed
in a message box.</P>
<P>The ReportError()function displays the message text directly in the familiar exception
message box and would be used from the catch block:</P>
<P>
<PRE>e-&gt;ReportError();
</PRE>
<H3><A NAME="Heading7"></A>Using the Memory Exception</H3>
<P>The CMemoryException is raised automatically when a C++ new<I> </I>keyword fails.
You can also raise it yourself using the AfxThrowMemoryException(); function. The
meaning of this exception is exclusively that Windows can't allocate any more memory
via its GlobalAlloc() or other memory allocation functions. This is a pretty dire
situation for any program; you would usually handle this exception by writing code
that lets your program die gracefully, freeing up memory and system resources as
it goes. There are rare cases in which you could take recovery action if you had
a large block of memory allocated and could free it without too much detriment to
the users' activities.</P>
<P>Due to the exclusivity of this exception, no other cause attributes or specific
functions extend the CException class's functionality.</P>
<P>You can watch new automatically raise a CMemoryException with these lines:</P>
<P>
<PRE>MEMORYSTATUS mem;
GlobalMemoryStatus(&amp;mem);
BYTE* pBig = new BYTE[mem.dwAvailVirtual+1];
</PRE>
<P>The mem.dwAvailVirtual structure member of MEMORYSTATUS will hold the total available
memory after the GlobalMemoryStatus() function retrieves the details. The new on
the next line requests one more byte than it could possibly have, thus throwing the
exception.</P>
<P>
<H3><A NAME="Heading8"></A>Using the Resource Exceptions</H3>
<P>CResourceException is thrown in many places where system resources are compromised,
as you saw in the mutex and semaphore example in Listing D.3. If you want to throw
these exceptions yourself, use the corresponding AfxThrowResourceException() function.</P>
<P>Windows can't find or allocate the requested resource and doesn't give any more
specific guidance; hence it has no other functions or attributes.</P>
<P>
<H3><A NAME="Heading9"></A>Using the File and Archive Exceptions</H3>
<P>You already looked at CFileException in Listing D.5. This is probably one of the
more sophisticated MFC exceptions because of the number of things that can go wrong
with file access. You can throw these yourself using the AfxThrowFileException()
function, which takes three parameters, one mandatory and the other two optional.
The first mandatory parameter, cause, is a cause code for the exception. This will
be placed in the file exception's m_cause member variable for interrogation in a
catch block.</P>
<P>Table D.1 shows a list of the various cause codes. The second parameter, lOsError,
can be used to specify an operating system error code to be placed in the file exception's
m_lOsError member variable. This long value can help clarify an error in more detail
by drawing on the operating system's own list of file access errors. The third parameter,
strFileName, is placed into the file exception's m_strFileName member string variable
to indicate the filename of the file that was being accessed when the error occurred.</P>
<P>
<H4>TABLE D.1.&nbsp;THE CFileException m_cause CODES.</H4>
<P>
<TABLE BORDER="1">
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">Cause Code		</TD>
		<TD ALIGN="LEFT">Meaning		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::none		</TD>
		<TD ALIGN="LEFT">There was no error.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::generic		</TD>
		<TD ALIGN="LEFT">No error code specified.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::tooManyOpenFiles		</TD>
		<TD ALIGN="LEFT">Too many concurrently open files.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::fileNotFound		</TD>
		<TD ALIGN="LEFT">Can't find the specified file.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::badPath		</TD>
		<TD ALIGN="LEFT">The path name specified is invalid.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::invalidFile		</TD>
		<TD ALIGN="LEFT">An attempt was made to use an invalid file handle.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::badSeek		</TD>
		<TD ALIGN="LEFT">The seek operation failed.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::endOfFile		</TD>
		<TD ALIGN="LEFT">The end of the file was reached.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::diskFull		</TD>
		<TD ALIGN="LEFT">There is no spare disk space.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::hardIO		</TD>
		<TD ALIGN="LEFT">A hardware error occurred.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::accessDenied		</TD>
		<TD ALIGN="LEFT">Permissions deny access to the file.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::directoryFull		</TD>
		<TD ALIGN="LEFT">The directory has too many files and can't add another.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::removeCurrentDir		</TD>
		<TD ALIGN="LEFT">Can't remove the current working directory.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::lockViolation		</TD>
		<TD ALIGN="LEFT">Can't lock an already locked region of the file.		</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">CFileException::sharingViolation		</TD>
		<TD ALIGN="LEFT">A shared region is locked or can't be shared.		</TD>
	</TR>
</TABLE>
</P>
<P>There is also a ThrowOsError()static member function that throws and configures
a file exception based on an operating system error code. You must pass ThrowOsError()
the operating system error code as its first parameter and an optional filename as
its second parameter. Another member function, ThrowErrno(), does the same thing
but uses the UNIX-style errno error codes as its only parameter (from the Errno.h
header file). Because these are static functions, you would use them with static
scope to raise exceptions with lines like this:</P>
<P>
<PRE>CFileException::ThrowOsError(ERROR_BAD_PATHNAME); 
&Acirc;// Invalid Path
CFileException::ThrowErrno (ENOSPC); // Disk Full
</PRE>
<P>Another static member function, OsErrorToException(), automatically converts between
operating system error codes and CFileException cause codes. By passing an OS error
code, it will return the corresponding cause code. A corresponding function ErrnoToException()
does the same when passed an errno error code.</P>
<P>When using archives with the CArchive class, you normally handle both CFileExceptions
and CArchiveException cases in conjunction: Many of the CArchive operations are tied