class for database handling errors

[Rahul]

Hi Everyone,

I'm currently developing a class for a database, each object of the
class will establish a connection to the database on a remote server
and and all of this happens on the constructor. So there are cases
when the connection can fail during the initial setup in the
constructor and i was wondering how to send this error to the caller.
Is it a good design to throw exceptions from the constructor? or is
there any other alternative?

Thanks in advance ! ! !

 

[Aggro]

I'm currently developing a class for a database, each object of the
class will establish a connection to the database on a remote server
and and all of this happens on the constructor. So there are cases
when the connection can fail during the initial setup in the
constructor and i was wondering how to send this error to the caller.
Is it a good design to throw exceptions from the constructor? or is
there any other alternative?

IMHO, don't do anything that can fail in the constructor. Create e.g. a
function called "Connect()" for establishing connections or "Create" for
some general initialization that can fail.

 

[Rahul]

IMHO, don't do anything that can fail in the constructor. Create e.g. a
function called "Connect()" for establishing connections or "Create" for
some general initialization that can fail.

Why do you say so? What is the class has a pointer and memory for
which needs to be allocated in the constructor for ensuring that the
object is successfully created?

 

[Ian Collins]

Hi Everyone,

I'm currently developing a class for a database, each object of the
class will establish a connection to the database on a remote server
and and all of this happens on the constructor. So there are cases
when the connection can fail during the initial setup in the
constructor and i was wondering how to send this error to the caller.
Is it a good design to throw exceptions from the constructor? or is
there any other alternative?

If construction of the object fails and this is an exceptional
condition, then throw an exception.

 

[Rahul]

If construction of the object fails and this is an exceptional
condition, then throw an exception.

Ok and what about the following case,

class exc
{
public: exc()
{
throw 5;
};
exc(const exc& ref)
{
throw 5;
}
};


int main()
{
try
{
exc obj; // causes an exception
}
catch(exc obj) // while handling the exception a new copy is
created which in turn throws the exception...
{
...
}
}

What about these situations where exceptions are generated when
exceptions are handled? I thought this is probably why constructors
and destructor shouldn't throw any exceptions at all...

 

[Jerry Coffin]

[ ... ]

catch(exc obj) // while handling the exception a new copy is
created which in turn throws the exception...
{
...
}
}

What about these situations where exceptions are generated when
exceptions are handled? I thought this is probably why constructors
and destructor shouldn't throw any exceptions at all...

IMO, you've picked up the wrong lesson here. The lesson should be
related to exception objects, not to ctors and/or dtors. First of all,
absent some _really_ good reason to do otherwise (which I've yet to
encounter) an exception handler should be written to receive a reference
to a (possibly const) object.

Second, exception objects should generally use fairly minimal resources
themselves in any case -- if (for example) an exception arises because
you've run out of available memory, an exception object that needs
megabytes of memory probably won't work -- and whether it attempts to
allocate that memory in its ctor or somewhere else makes no real
difference.

The language doesn't make any categorical requirements about exception
objects separate from other objects. Nonetheless, well-designed
exception classes bear little resemblance to well-designed classes of
other sorts.

 

[hurcan solter]

Ok and what about the following case,

class exc
{
public: exc()
{
throw 5;
};
exc(const exc& ref)
{
throw 5;
}
};


int main()
{
try
{
exc obj; // causes an exception
}
catch(exc obj) // while handling the exception a new copy is
created which in turn throws the exception...
{
...
}
}

this doesn't catch the exception..

 

[James Kanze]

I'm currently developing a class for a database, each object of the
class will establish a connection to the database on a remote server
and and all of this happens on the constructor. So there are cases
when the connection can fail during the initial setup in the
constructor and i was wondering how to send this error to the caller.
Is it a good design to throw exceptions from the constructor? or is
there any other alternative?

Normally, the preferred solution when a constructor cannot
create the object correctly is for it to raise an exception.
This case is, however, a somewhat special case, since you (and
the client code) also has to be prepared to handle the loss of a
connection---this means that you have to be able to deal with an
object without a valid connection. Raising an exception might
still be the correct solution (including raising one if you
detect a missing connection later), but in this case, it doesn't
free you from having to deal with an object which might not have
a valid connection. Regardless of how you notify the client
code, you still have to maintain some sort of internal state as
to whether there is a connection or not, and check it before
each operation (or at least ensure that the operation fails if
there is no valid connection).

 

[James Kanze]

[...]

First of all,
absent some _really_ good reason to do otherwise (which I've yet to
encounter) an exception handler should be written to receive a reference
to a (possibly const) object.

I have. It's a special case, but in some applications, where
it would normally make sense to call exit() somewhere deep in
call hierarchy, I adopt the convention of throwing an int (the
return code) instead; main catches int and returns. In other
words, I call exit, but only after having executed all of the
intermediate destructors. And of course, there's no point in
catching int with a reference.

(For the rest, I agree with all you've said. I just thought I'd
mention this one special case.)