Re: I keep running into long term c++ programmers who refuse to use exceptions
"WalterHoward@gmail.com" <walterhoward@gmail.com> wrote:
A simple example of how you might use exceptions:
FILE* FileOpen(const char* filename, const char* mode)
{
FILE* theFile = fopen(filename, mode);
if ( !theFile)
throw "Error opening file";
return theFile;
}
int main(int argc, char* argv[])
{
try
{
FILE* theFile = FileOpen("testfile.txt",
"r");
// Do something with the file
}
catch(const char* error_string)
{
// If FileOpen fails we come immediately
to here, skipping "Do someth ing with the file"
puts(error_string);
exit(-1);
}
exit(0);
}
If FileOpen() fails, it throws an exception which immediately unravels
all functions that were already called within try and executes the
code contained in catch.
C++ provides you this syntax of exceptions. It doesn't tell you how to
use exceptions well. I'll try to provide some help with that.
The first important rule to remember about using exceptions well is
that (with a few exceptions) you should only throw an exception when a
function fails to perform its job. The reason for doing this is part
and parcel of the philosophy for using exceptions and is embedded in
the very name of the concept: exception. Exceptions should be thrown
when the normal, expected flow of your program experiences an oddity,
an exception. What is normally called an error falls into this
category also.
Your not quite there IMHO, but you are close. I suggest you read up on
design by contract. Exceptions should be used when contracts are broken.
Whenever you write a function you have to ask yourself:
What does the function require?
What does the function guarantee?
Now, obviously if you are writing a function and it fails to meet its
guarantees despite having everything it requires, you have written the
function incorrectly. In this case, you couldn't have thrown an
exception before knowing the error existed, and once you discover the
error, you should fix the code rather than add code to throw an
exception.
However, when you are writing a function, what should that function do
if its requirements have not been met? This is where exceptions come in.
The function cannot do its job (whatever that is,) because it doesn't
have what it needs to get the job done.
Good examples of proper exception use are already in the standard
library, so let's have a look at some:
Both vector and deque have member-functions called "at()" and these
functions are guaranteed to return the value at a particular index
within the container. In order for the function to be able to meet its
guarantee, it requires that the parameter passed in refers to an element
in the container. Giving a bad parameter is a requirement violation, the
function cannot do its job, so it throws an exception.
When dynamic_cast is passed a reference, it guarantees that it will
return the the referenced object as the specified derived type. The
function requires that the referenced object actually is the type
specified. If its requirements aren't met, then it can't do its job, so
it throws an exception.
The above are just two examples, but you get the idea I'm sure.
For your example, the fact that your FileOpen function throws an
exception if the file doesn't exist means that it is an *error* to call
FileOpen and pass in the name of a nonexistent file. What this means is
that if FileOpen throws its exception during some run of the program,
you should *not* add a catch, instead you should fix the code so the
exception is no longer thrown.
If your code is littered with catches that are empty, or catches that do
something other than error logging and re-throw/exit, then you have
poorly written code.
It is important for functions to throw exceptions when they can't do
their specified jobs, but catches should be nearly absent from the code
base.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]