![]() |
![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
[an error occurred while processing this directive]
Finally, the definition for func3() is encountered. If you recall, this function guarantees to not throw an exception. As you can see by the empty definition, the guarantee is fulfilled. Comments Utilizing exception specifications leads to readable and maintainable source code. The use of exception specifications also provides a form of self-documenting code. The other option you have is to furnish comments at the declaration and definition for a function that throws exceptions. The problem with that is the lack of consistency; someone might add an exception within the definition and forget to document the declaration. Once again, an exception specification follows a functions argument list and consists of the keyword throw, followed by a list of exception types encased within parentheses. If the exception list is empty, the function guarantees not to throw an exception. What if a function throws an exception not specified within the exception specification list? You might think the compiler could catch the various exceptions thrown by examining the throw statements. In reality, the compiler isnt quite that smart. The following example illustrates that fact: void f() throw( int ) { int i, j , k ; //... k = i / j ; //... } This function definition states that the function will only throw an exception of type int. The problem is that a divide-by-zero exception could be thrown; the compiler cant possibly know this. Im sure a compiler vendor can provide a compiler switch to produce a warning message whenever it encounters a division expression. However, I assume most developers would turn that switch off, especially if developing an accounting package. The point is that you should not rely on the exception specification to tell you all the exceptions a function will throw. What if a function throws an exception not listed within the exception specification? The library function unexpected() is called. This will happen only if the function does not handle the unknown exception. For example, you might provide the catch-all catch clause for this purpose. The default action for unexpected() is to invoke the library function terminate(). It might be in your best interest to override unexpected() so you can control its behavior. How-To 11.5 explains how to handle this situation. 11.5 Handle exceptions that are not caught or not expected?Problem The applications I am writing include exception handling, but exceptions are still being thrown. Is there any way that the application can process unhandled exceptions gracefully? Technique In this How-To, you will see how to handle exceptions that are not handled or unexpected. Although you might provide exhaustive measures to handle exceptions, there will be instances in which exceptions are missed. The example provided here will help alleviate uncaught exceptions. Steps
|
![]() |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-1999 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permision of EarthWeb is prohibited.
|