Exception Handling in Insight

[Josh Cates]

Hi Luis,

I think my code example was a little misleading because I omitted
examples of the subclasses.  We do actually subclass the base class for 
specific error types as you suggest.  The enumerated types are sort of
a back up system so that a user can query for type information at run
time.  They also point to some default messages.

A typical subclass looks like:

// Matrix error
class Matrix : public Err
 {
  public:
	Matrix() : Err() { setType(Matrix_t); }
	~Matrix() {}
	Matrix(const char *m) : Err(m) {setType(Matrix_t); }
	Matrix(const char *m, const char *l) : Err(m,l) 
           {setType(Matrix_t);}
	Matrix(const Matrix& orig) { assign(orig); }
	Matrix& operator=(const Matrix& orig) 
           { assign(orig); return *this; }
  };

There is probably a more elegant way to do run-time type identification,
mine was just a quick and easy solution.  In general, users shouldn't have
to query exception objects for their type (getType() method) because the
C++ error trapping mechanism handles the type identification for them.

Sorry for the confusion,

Josh.

+--+--+--+--+--+--+--+--+--+--+--+--
 Josh Cates			
 Dept. of Electrical Engineering	
 University of Tennessee, Knoxville
 Email: jecates at utk.edu
 Phone: (865) 974-0694
 URL:   www.cs.utk.edu/~cates
--+--+--+--+--+--+--+--+--+--+--+---

On Fri, 14 Apr 2000, Luis Ibanez wrote:

> 
> Hi,
> 
> 
> I fully agree with the advantages of using
> exceptions described in the white paper
> sent by Josh.
> 
> My only comment is about the implementation
> used in VISPack.  The base class for error
> (exceptions) has an "enum" type with error codes
> and an array of strings (messages) associated
> with the error codes.
> 
> enum Err_t { Undef_t=0......}
> const char ErrType [][ErrType_sz] = {"Undefined","Out of
> range".....}
> 
> This is a bit contradictory with the statements
> presented in the paper, because is still using the
> mechanism of setting error codes that have to
> be tested elsewhere. It is in some way like keeping
> the "errno"  C variable alive but hidding inside
> the error class.
> 
> Each time that a new error type is added this list
> will have to be modified.
> 
> It will be cleaner to follow the recomendations
> of the paper an implement a hierarchy of classes
> in which there is a class corresponding to each
> one of the possible error types. The identity of
> the class itself will define the type of error produced.
> 
> The message can be initialized with a default message
> in the constructor of each specific error class.
> 
> New error types can be added just by creating new
> classes deriving from the ones already existing in
> the hierarchy.
> 
> 
> 
> Anyway, this is just an implementation detail,
> I think it will be for our advantage to use
> exceptions as error handling mechanism as Josh
> proposed.
> 
> 
> -----
> 
> Additional information on the use
> of exceptions can be found in
> 
> Effective C++ CD
> Addison-Wesley
> Scott Meyers
> ISBN 0-201-60614-3
> 
> Some advices about how to
> make good use of exceptions
> can be found in :
> 
> C++ Report
> http://www.creport.com/
> March 1996
> "Coping with Exceptions"
> by Jack W. Reeves.
> 
> and  in C++ Report too
> (sep, and nov-dec 1997)
> "Exception-Safe Generic Containers"
> by Herb Sutter
> With comments about how to safely
> use exception with templates.
> 
> -----
> 
> 
> 
> 
> Luis.
> 
> 
> --
> 
> ______________________________________________________________________
> 
> Luis Ibanez
> Research Assistant Professor - Division of Neurosurgery
> University of North Carolina at Chapel Hill
> Sitterson Hall, CB#3175, Chapel Hill, NC 27599
> email : ibanez at cs.unc.edu       home  :
> http://www.cs.unc.edu/~ibanez
> phone : (919)-962-1907          fax   : (919)-962-1799
> 
> ______________________________________________________________________
> 
> 
> 
>