Re: is such exception handling approach good?

On Dec 22, 11:33?am, ajk <a...@workmail.com> wrote:


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

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.