class for database handling errors

Discussion in 'C++' started by Rahul, May 10, 2008.

  1. Rahul

    Rahul Guest

    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 ! ! !
     
    Rahul, May 10, 2008
    #1
    1. Advertising

  2. Rahul

    Aggro Guest

    Rahul wrote:

    > 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.
     
    Aggro, May 10, 2008
    #2
    1. Advertising

  3. Rahul

    Rahul Guest

    On May 10, 3:14 pm, Aggro <> wrote:
    > Rahul wrote:
    > > 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.


    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?
     
    Rahul, May 10, 2008
    #3
  4. Rahul

    Ian Collins Guest

    Rahul wrote:
    > 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.

    --
    Ian Collins.
     
    Ian Collins, May 10, 2008
    #4
  5. Rahul

    Rahul Guest

    On May 10, 4:37 pm, Ian Collins <> wrote:
    > Rahul wrote:
    > > 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.
    >
    > --
    > Ian Collins.


    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...
     
    Rahul, May 10, 2008
    #5
  6. Rahul

    Jerry Coffin Guest

    In article <e770d853-b9f1-4898-91f0-
    >, says...

    [ ... ]

    > 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.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, May 10, 2008
    #6

  7. >On May 10, 4:37 pm, Ian Collins <> wrote:
    >> Rahul wrote:
    >> > 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.
    >>
    >> --
    >> Ian Collins.

    >
    >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..
    >
    > 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...
     
    hurcan solter, May 10, 2008
    #7
  8. Rahul

    James Kanze Guest

    On 10 mai, 11:58, Rahul <> wrote:

    > 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 (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 10, 2008
    #8
  9. Rahul

    James Kanze Guest

    On 10 mai, 15:19, Jerry Coffin <> wrote:

    [...]
    > 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.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, May 10, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Goldin

    Errors, errors, errors

    Mark Goldin, Jan 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,031
    Mark Goldin
    Jan 17, 2004
  2. E11
    Replies:
    1
    Views:
    4,944
    Thomas Weidenfeller
    Oct 12, 2005
  3. Rhino
    Replies:
    1
    Views:
    407
    Oliver Wong
    Jan 19, 2006
  4. Steve
    Replies:
    2
    Views:
    299
    John Harrison
    May 10, 2004
  5. SenthilVel
    Replies:
    0
    Views:
    977
    SenthilVel
    Jun 7, 2006
Loading...

Share This Page