TITLE: a good design decision for exceptions

PROBLEM: Thomas Trenz (trenz@ids.saarlink.de)

 we are developing a new application in which we want to
 use Exception-Handling. We decided to create a base class
 for all exceptions, which is defined as follows:

 class ExceptionBase
 {
 public:

   ExceptionBase (LPCSTR lpszFile, int Line);
   virtual ~ExceptionBase () {}

   // Informationsfunktionen...
   const String & File () const { return sFile; }
   int            Line () const { return nLine; }

 private:

   String sFile;
   int    nLine;
 };

 My question is:

 * Is that a useful baseclass?
 * Or are there any better suggestions?


RESPONSE: hopps@mmm.com (Kevin J Hopps), 20 Jun 95

When we designed our exception class hierarchy, we adopted the policy
that exception classes cannot themselves cause anything to throw an
exception.  It is likely that the embedded String class could fail
under certain circumstances (e.g. out of memory).

The base class we designed had four data members:
    const char* m_file;		// presumably the value of __FILE__
    unsigned m_line;		// from __LINE__
    char m_why[256];		// derived classes may set this
    char m_func[128];		// prototype of throwing function

We used fixed size arrays so that no dynamic memory allocation was
required (this can fail, after all).

We also decided not to derive new exception classes unless the code
catching the exception had a need for additional information for the
purpose of performing error recovery.  This kept the number of
classes relatively small.  I believe we ended up with about ten.