Re: throwing exceptions from constructor and other alternatives
alfredo.correa@gmail.com wrote:
Throwing from a constructor is just ugly -
the language does not prevent it, but semantically it is just 'I dont
have the right word for it'... wrong...
That is what I wanted to hear. Because I suspected it.
That may be what you wanted to hear but I do not know of any experienced
user of C++ who would say that. Throwing from a constructor is an
essential technique. Two stage construction just does not work when you
include serious use of inheritance, and even less when you use
templates.
I don't know, I have mixed fillings now. Many people is saying that
throwing from constructor is totally normal, however how do you think
the resulting syntax will look like?
try{
object construtor
use of object
}catch(...){
object construtor with alternative values
SAME use of object
}
...Well, maybe it is the way to go.
an object with a status flag (ala std::stream) may not be worst or
better alternative.
The problem here is not throwing an exception from a constructor - the
problem is that an object is being constructed at all. Finding the root
of a number does not describe a class object - it describes a process
that applies an algorithm to input data in order to produce a result.
And as an algorithm, finding the root is most sensibly implemented as a
function - not as some kind of object.
It is easy to get carried away with object-oriented design and try to
create objects for everything - but the object-oriented approach is not
the best choice for every task. There are many reasons (aside from the
constructor issue) why a "root finder" object is not well-suited for
the task of finding roots. For example, consider destruction. An
algorithm eventually reaches a conclusion - the root is found - and the
process terminates itself by returning with its result. An object in
constrast does not reach any sort of self-directed "conclusion" -
rather an object is typically deleted by an owning agent for as part of
a larger process (or object) of which the object is only a part. In
other words, what is the value in keeping a root finder object around
after the root has been found?
Implementing root finding as a function would also resolve the issue
with exceptions. Since the inputs are guesses in the first place, and
the corrective action for unsuitable values is already known - a
function would not throw an exception back to the caller when passed
unsuitable values. The function could simply adjust the guesses passed
by the client, and thereby encapsulate the entire root-finding process
into a single routine that clients can invoke without having first to
take precautionary measures.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]