Re: is such exception handling approach good?
On Dec 22, 11:33 am, ajk <a...@workmail.com> wrote:
On Fri, 21 Dec 2007 17:36:15 +0200, "Alex Blekhman"
<tkfx.REM...@yahoo.com> wrote:
I beg to differ. It is exactly the opposite. Splitting
object's construction into two parts introduces unnecessary
and dangerous period when object's state is undetermined.
There is nothing wrong with throwing from constructor. You
won't end up with invalid object. You end up with valid
working object if the constructor succeeds, or no object at
all, otherwise.
Alex
I think there are several reasons why one shouldn't have too much code
in the ctor.
One reason is that the state of the object is not defined. If you
instead have the functionality in other member functions you have more
control on the state of the object and better handle the error
conditions and cleanup.
Say if a class initializes some memory, grabs some resource and opens
an oracle database in the ctor then what should you do with the object
if one of those three failed? IMO it is not a good design to stuff all
this initialization in the ctor.
It may be a good design, it may not be a good design from user's point
of view. The user might want to have a class wherein, by default he
doesn't get the connection created automatically on object creation.
But if it makes sense for the user of the class that those many
processings must be done automatically upon object creation, then from
C++ point of view it is achievable, with clarity and with stability.
You can use some sort of a smart pointer that does automatic cleanup
on stack unwinding if exception is raised. You can call the release
resource API to free-up the resource on exception. You can close the
connection if something else in the constructor threw after opening
it. These all can be based on RAII and you would not need to do
anything specific for exception handling yourself. Here:
MyClass::MyClass()
{
//could wrap the logic inside a private member if the
constructor code would be shared...
shared_ptr<someclass> shptr(new someclass());
mem_shared_ptr = shptr;
//GrabAResource();
try{
OpenConnToDB();
}catch(...) //whatever specific exception catch
{
//ReleaseAResource();
}
}
The above constructor is exception safe now. If new someclass fails-
either through bad_alloc or any other exception from its own or its
base or any other member's constructor - or even if GrabAResurce()
fails then the code does not leak and that exception can be let to
pass through for the caller to handle it as appropriate. If
OpenConnToDB fails, the shared_ptr makes you not worry about it. But
the resource might need some attention if it is not RAII based. You
call a release for it in the handler. What do you not like about it?
It is exception safe, it is clear code and it is maintainable. (you
may have some refactoring into smaller functions if it makes the
constructor look more cluttered). Note that the important point is -
can the user want to have all these tasks done in the constructor? It
may not be - then you need to change but still this is a better design
if users need not much worry about constructors.
I am not saying you should not have individual member to take up those
individual bulkier tasks - but I am saying there is nothing wrong as
far as exception safety is concerned. If you are calling something as
*Initialization* - in an objects lifetime - that should happened once
- and while construction of the object. If want to allow user to
change something - that is not initialization. The user can have
option to close()/open() DB connection, can have option to grab()/
release() resource etc. but that depends on if the user needs it or
needs to know about it. Taking up a connection to the DB is an
intensive task - it might be opted to not take up a connection by
default and have the caller make an explicit call for it. But those
are different design points which are not related to exception safety.
However if you instead have split up the initialization in three
functions you are more clear how to handle failure of any of these
three and whether or not you should proceed. The code gets clearer for
somebody else to read it.
The question of whether or not to proceed can be dealt with either of
the design paths you choose. Which one is cleaner if of course
subjective, depends on design path chose, depends on how you would
define *Initialization* for MyClass (taking other things into
consideration - including performance).
It gets even worse if the class with the complex initialization has
been derived from some baseclass - if one of the base classes throws
an exception.
This is a no-worries situation! Classes should make themselves
exception safe. If a base class throws an exception, other bases
initialized before this specific base should be capable of rolling
themselves back - RAII - their destructor will be called! The derived
class initialization does not begin until base's is successful. How is
the situation worse?
My point is: just to reiterate: there is no problem as far as
exception safety is concerned.