[Insight-developers] RE: pure virtual methods vs exceptions throwing

[Lorensen, William E (CRD)]

The LevenbergMarquardtTest was throwing an exception.

Why don't the subclasses of CostFunction provide the required methods? 

-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
Sent: Wednesday, February 27, 2002 9:41 AM
To: Lorensen, William E (CRD)
Cc: insight-developers@public.kitware.com
Subject: pure virtual methods vs exceptions throwing



Bill,

I have been hesitating about how to manage these cases
and would appreciate any comments on how to do it better.

It is happening now in Transforms, CostFuctions,
Spatial Functions and a couple of other classes.

The problem is:

In order to remove template parameters we went back to
classical C++ where we have hierarchies of classes (e.g.
a hierarchy of transforms, a hierarchy of optimizers, a hierarchy
of cost functions). Each hierarchy has a Base class that works
as a generic representative of all the hierarchy members.

Classes that require a Transform only keep a SmartPointer to
the base class of the Transform hierarchy...and so on.
At run time, the user will plug in a real functional member of the
hierarchy into the pointer to the generic one and all the calls will
be done via virtual functions.

The Base classes of the  hierarchy are quite dummy. They are
devoid of  all functionality in themselves and are never expected
to be instantiated.   So in principle most of their methods could
be declared pure virtual:

    virtual     method()   = 0;

but...

For some reason, classes that hold smart pointer to these
base classes try to instantiate them as construction time.
That results in a message like:

         class YYY cannot be instantiated because
         the method ZZZ is abstract.

This is triggered by the      itkNewMacro() .... as current
messages from the SGIs show in the dashboard.

In order to avoid this, I removed pure virtual from methods
in the base classes and wrote dummy implementations for them.
This has the risk that classes deriving from them may forget
to overload these dummy method and they may end up being
called at run-time producing  absurd results.

So....I throw exceptions on them !

These methos should never be called.
If they are called that means that a derived class
is not overloading a method that must be overloaded....

If the run time test were crashing because of exceptions
that means that some derived class was not being correctly
implemented.


======================================
To summarize:

It looks like we have two options:

1) Go back to pure virtual methods (and find a workaround
for the itkNewMacro() instantiation problem. That will give
compile-time error is some derived class is not overloading
the right methods.

2) Keep methods just virtual and do something to signal
that this method should not be called... that can be:
- Keep throwing exeptions.
- Print some kind of message .. Warning.. Error....
=======================================

Any  advice on this will be welcome !


===================================
Lorensen, William E (CRD) wrote:

>Luis,
>	 Subclasses of CostFunction were throwing an exception if the method GetNumberOfParameters
>was not defined. This was causing some optimizer tests to crash. These required methods should
really
>be pure virtual so that the compiler detects the missing method. I changed CostFunction to do this
so
>you may see a few more compile errors show up.
>
>Bill
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers
>