Well, C++ programmers must deal with exception handling eventually, like
it or not. Right now, exceptions are not widely used yet because:
1. The standard is still new.
2. People don't understand them well, and make many mistakes.
3. Compilers don't understand them well, and make many mistakes.
4. Misunderstandings about the performance implications.
As time moves forward, compilers will get better (some already handle
exceptions very well) and people, especially API / library writers,
will start using them extensively. Note that the Standard C++ library
and the STL already use exceptions.
That automatically means anyone and everyone using those libraries
must understand and deal with exceptions. An unhandled exception is
by default a fatal error, terminating the program.
Even simple statements can generate exceptions. Suppose you bought a new
PalmOS C++ library with a PalmApp class:
PalmApp foobar = new PalmApp; // operator new and "PalmClass" c-tor
// can both throw exceptions.
foobar.LoadDB ("nonexistentfile"); // Perhaps even this will throw one.
Complicating matters in C++ are that programmers can throw any exception
type they want, and compilers aren't strict about checking throw specifiers.
Java fixes some of these concerns.
Bottom line is, in the "near" future, dealing with exceptions will not be
an option.
Regards,
-Ade
At 11:21 AM 5/6/99 -0400, Greg Winton wrote:
>>I've got a constructor that does some memory allocation and creates a
>>record for the app, etc. I am now trying to add nice error handling if the
>>alloc's fail in the constructor [...]
>This is where you might use an exception. However, exceptions are things
>that are best used sparingly, if at all. [...]
