errors inside a constructor

[Boogie El Aceitoso]

Hi,

I have a class whose constructor accepts a filename and performs some actions
on it[1].

Some things might go wrong, such as not being the right kind of file, the file
doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an
exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....

IS this the best design? Any comments would be appreciated. O:-)

[1] I don't think it's relevant but in case you're curious, it reads all the
version information on it (product name, comapny name, etc...)

[Gianni Mariani]

Boogie El Aceitoso wrote:

Hi,

I have a class whose constructor accepts a filename and performs some actions
on it[1].

Some things might go wrong, such as not being the right kind of file, the file
doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an
exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....

IS this the best design? Any comments would be appreciated. O:-)

It all depends on what you're trying to do.

If you're doing somthing simple, batch mode - come in - go out - not
concering yourself with other kinds of things (like changes to the file
once it has been read) etc, then refusing to create the object by
throwing an exception is fine. However, if you're trying to do more
complex things, you might want to allow creation of the object and
handle the various states that the "concept" may be in. In other words,
it goes back to requirements. Maybe it is a flaw of mine but I try very
hard not to use exceptions.

[Oplec]

Boogie El Aceitoso wrote:

Hi,

I have a class whose constructor accepts a filename and performs some actions
on it[1].

Some things might go wrong, such as not being the right kind of file, the file
doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an
exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....

IS this the best design? Any comments would be appreciated. O:-)

[1] I don't think it's relevant but in case you're curious, it reads all the
version information on it (product name, comapny name, etc...)

I would throw an exception. Class constructors are meant to bring a
class object into a good state and establish an invariant that the other
member functions maintain when used. If you don't throw an exception,
and the class can not be used, then the user will have to check for a
result after creating each object of your class and your classes members
will either have to assume that the object is in a good state, or always
check before being used and signal an error which the user will have to
test at each call. Throwing an exception is the correct method.
Exceptions don't have to be just used for devastating errors.

I'm relatively new to C++, but that much has been drilled into me by Mr.
Stroustrup.

[Julián Albo]

Boogie El Aceitoso escribió:

I have a class whose constructor accepts a filename and performs some actions
on it[1].

Some things might go wrong, such as not being the right kind of file, the file
doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an
exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....

If the class need a valid file to be in a valid state, throw an
excepcion seems perfectly fine for me. And is easier catch the
excepction in an upper level that write a battery of if ...

And I don't see nothing extreme in the use of exceptions. Is an element
of the language like any other.

Regards.

[Victor Bazarov]

"Boogie El Aceitoso" <fr****@telefonica.net> wrote...

I have a class whose constructor accepts a filename and performs some actions on it[1].

Some things might go wrong, such as not being the right kind of file, the file doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....

IS this the best design? Any comments would be appreciated. O:-)

There IS no "best" design. The design should be suited to your needs.

One more possibility is a member variable that would indicate success
or failure to construct your object properly. You could use it this
way:

MyClass obj(filename);

if (obj.good()) { // 'good' is an accessor to that member var
.. continue
}
else {
.. errors creating 'obj' (or processing the file)
}

Victor

[Mark Kerns]

> Hi,

I have a class whose constructor accepts a filename and performs some actions on it[1].

Some things might go wrong, such as not being the right kind of file, the file doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....

IS this the best design? Any comments would be appreciated. O:-)

[1] I don't think it's relevant but in case you're curious, it reads all the version information on it (product name, comapny name, etc...)

It's a religious issue. You could for instance establish an error state
instead and have the caller test your object for success or failure (let me
know if you need instructions on how to code this). You then do this:

CYourObject YourObject(Whatever);
if (YourObject)
{
// Success
}
else
{
// Failure
}

Of course you're then forced to always check for this and other developers
that might use your class will have to check as well. If not and your class
depends on the file being successfully opened then all other class methods
will have to be robust against failure. That is, they will all have check
the state of the file before processing or otherwise respond accordingly
when something fails because the file was never opened. This can get very
tedious of course (and code-intensive, something you want to avoid if
possible). In any case, your decision also depends on whether a "can't open
file" problem is really a critical error in this class. If it is and your
class really can't proceed without this file (and no separate "Open()"
method exists so the caller can correct the problem and try again) then an
exception is fine. In fact, I would even recommend it (I use them all the
time) and you need not even put a try/catch around it in many cases. You
need only do so in the top-level function only, especially where the
situation is considered a critical error and you need to back out of
everything you're doing. One caveat however. Your class' destructor won't be
called if its constructor throws an exception (standard C++ rule). So make
sure you release any other resources that you normally depend on your
destructor to free (as req'd).

[Gene Wirchenko]

On Mon, 03 Nov 2003 17:49:52 +0100, Boogie El Aceitoso
<fr****@telefonica.net> wrote:

I have a class whose constructor accepts a filename and performs some actions
on it[1].

Some things might go wrong, such as not being the right kind of file, the file
doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an
exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....
Can you subsequently do anything sensible with the object if the
file access fails?

If yes, then set a member variable flag appropriately.

If not, then you have an exceptional situation. Throw the
exception.
IS this the best design? Any comments would be appreciated. O:-) [1] I don't think it's relevant but in case you're curious, it reads all the
version information on it (product name, comapny name, etc...)

Sincerely,

Gene Wirchenko

[NFish]

Boogie El Aceitoso wrote:

Hi,

I have a class whose constructor accepts a filename and performs some actions
on it[1].

Some things might go wrong, such as not being the right kind of file, the file
doesn't exist, is read-only, etc...

I guess the only way to report an error inside a constructor is to raise an
exception, but it feels a bit extreme to raise an exception becuase a file
couldn't be found....

IS this the best design? Any comments would be appreciated. O:-)

[1] I don't think it's relevant but in case you're curious, it reads all the
version information on it (product name, comapny name, etc...)

There is no best design, of course. But how does the istream class
handle file not found? You could take a hint from that.