Re: on the matter of exceptions

I use a very shallow exception hierarchy, often only one class
"Exception" derived from std::exception. I find programmers
obsessively classify things into different categories way ahead of the
actual need to do so, and this is what most of them have done with
exceptions.

The class looks something like this:

class Exception
{
   std::string Message; // free form text often filled in by
strerror() or the equivalent
   std::string Location; // file:line
   std::string StackTrace; // see gcc header execinfo.h, function in
backtrace()
   int SystemError; // the Operating system error code if one
exists (example 2 file not found)
   int ApplicationError; // an error code more apropos to the
application itself (example 27 invalid username).

   // member functions left as an exercise for the reader.

 };

The thrower should not be concerned about how the exception is
handled. All he should do is throw as much information as possible and
that Exception class gives you just about all there is to know. It is
not the job of the thrower to be concerned with how the exception is
handled. I find exception hierarchies unnecessary and productive of
kludge.

I mostly catch like this:

catch(const Exception& e)
{
}
catch(const std::exception& e)
{
   // Only because other libraries I might be using subclass from
std::exception
}

Catching (...) should only be done in production code as a last resort
and never during development as it quashes errors. One of the major
reasons to use exceptions is to make sure errors get handled. Having
said that, never say never.

Programmers have all sorts of standards they use to define WHEN to
throw an exception. I use one simple rule: If the function cannot
fulfill its purpose, throw an exception. That what exception means:
outside of the domain I am designed to handle.

A common example is a FileOpen function, like this:

int FileOpen(const char* name, int flags)
{
   int rval = ::open(name, flags);

   if (rval == -1)
   {
       /*
       BIG ARGUMENT HERE. Return rval? return 0? throw exception?
       The caller of this function is depending on getting an open
file. That's why he called it. If he doesn't get an open
       file we can assume he's screwed too and cannot continue with
his task. I say the proper thing to do is
       throw an exception. If you follow this philosophy your code
becomes at least 5x less complex.
       */

   }
   return rval;
}

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]