Throwing exceptions from constructors

Question

I m having a debate with a co-worker about throwing exceptions from constructors  and thought I would like some feedback   Is it OK to throw exceptions from constructors  from a design point of view   Lets say I m wrapping a POSIX mutex in a class  it would look something like this   class Mutex   public    Mutex         if  pthread mutex init  amp mutex   0     0          throw MutexInitException                  Mutex         pthread mutex destroy  amp mutex           void lock         if  pthread mutex lock  amp mutex      0          throw MutexLockException                 void unlock         if  pthread mutex unlock  amp mutex      0          throw MutexUnlockException               private    pthread mutex t mutex        My question is  is this the standard way to do it  Because if the pthread mutex init call fails the mutex object is unusable so throwing an exception ensures that the mutex won t be created   Should I rather create a member function init for the Mutex class and call pthread mutex init within which would return a bool based on pthread mutex init s return  This way I don t have to use exceptions for such a low level object

User · Answer

Throwing an exception is the best way of dealing with constructor failure. You should particularly avoid half-constructing an object and then relying on users of your class to detect construction failure by testing flag variables of some sort.

On a related point, the fact that you have several different exception types for dealing with mutex errors worries me slightly. Inheritance is a great tool, but it can be over-used. In this case I would probably prefer a single MutexError exception, possibly containing an informative error message.

User · Answer

Apart from the fact that you do not need to throw from the constructor in your specific case because pthread mutex lock actually returns an EINVAL if your mutex has not been initialized and you can throw after the call to lock as is done in std  mutex   void lock       int   e     gthread mutex lock  amp  M mutex         EINVAL  EAGAIN  EBUSY  EINVAL  EDEADLK may    if    e    throw system error   e       then in general throwing from constructors is ok for acquisition errors during construction  and in compliance with RAII   Resource-acquisition-is-Initialization   programming paradigm   Check this example on RAII   void write to file  const std  string  amp  message           mutex to protect file access  shared across threads      static std  mutex mutex          lock mutex before accessing file     std  lock guard lt std  mutex gt  lock mutex           try to open file     std  ofstream file  example txt        if   file is open            throw std  runtime error  unable to open file            write message to file     file  lt  lt  message  lt  lt  std  endl          file will be closed 1st when leaving scope  regardless of exception         mutex will be unlocked 2nd  from lock destructor  when leaving        scope  regardless of exception      Focus on these statements    static std  mutex mutex std  lock guard lt std  mutex gt  lock mutex   std  ofstream file  example txt      The first statement is RAII and noexcept  In  2  it is clear that RAII is applied on lock guard and it actually can throw   whereas in  3  ofstream seems not to be RAII   since the objects state has to be checked by calling is open   that checks the failbit flag   At first glance it seems that it is undecided on what it the standard way and in the first case std  mutex does not throw in initialization    in contrast to OP implementation     In the second case it will throw whatever is thrown from std  mutex  lock  and in the third there is no throw at all    Notice the differences    1  Can be declared static  and will actually be declared as a member variable  2  Will never actually be expected to be declared as a member variable  3  Is expected to be declared as a member variable  and the underlying resource may not always be available   All these forms are RAII  to resolve this  one must analyse RAII    Resource   your object Acquisition   allocation     you object being created Initialization   your object is in its invariant state   This does not require you to initialize and connect everything on construction  For example when you would create a network client object you would not actually connect it to the server upon creation  since it is a slow operation with failures  You would instead write a connect function to do just that  On the other hand you could create the buffers or just set its state   Therefore  your issue boils down to defining your initial state  If in your case your initial state is mutex must be initialized then you should throw from the constructor  In contrast it is just fine not to initialize then   as is done in std  mutex    and define your invariant state as mutex is created   At any rate the invariant is not compromized necessarily by the state of its member object  since the mutex  object mutates between locked and unlocked through the Mutex public methods Mutex  lock   and Mutex  unlock     class Mutex   private    int e    pthread mutex t mutex    public    Mutex    e 0      e   pthread mutex init  amp mutex           void lock          e   pthread mutex lock  amp mutex        if  e    EINVAL                 throw MutexInitException              else  e           throw MutexLockException                        the rest of your class

User · Answer

include  lt iostream gt   class bar   public    bar           std  cout  lt  lt   bar   called   lt  lt  std  endl          bar           std  cout  lt  lt    bar   called   lt  lt  std  endl          class foo   public    foo         b new bar            std  cout  lt  lt   foo   called   lt  lt  std  endl      throw  throw something           foo           delete b      std  cout  lt  lt    foo   called   lt  lt  std  endl       private    bar  b       int main void      try       std  cout  lt  lt   heap  new foo   lt  lt  std  endl      foo  f   new foo        catch  const char  e        std  cout  lt  lt   heap exception     lt  lt  e  lt  lt  std  endl         try       std  cout  lt  lt   stack  foo   lt  lt  std  endl      foo f      catch  const char  e        std  cout  lt  lt   stack exception     lt  lt  e  lt  lt  std  endl         return 0      the output   heap  new foo bar   called foo   called heap exception  throw something stack  foo bar   called foo   called stack exception  throw something   the destructors are not called  so if a exception need to be thrown in a constructor  a lot of stuff e g  clean up   to do

User · Answer

It is OK to throw from your constructor  but you should make sure that your object is constructed after main has started and before it finishes   class A   public    A          throw int             A a         Implementation defined behaviour if exception is thrown  15 3 13   int main        try            Exception for  a  not caught here        catch  int

User · Answer

If you do throw an exception from a constructor  keep in mind that you need to use the function try catch syntax if you need to catch that exception in a constructor initializer list   e g   func  func     foo         try           catch          will NOT catch exceptions thrown from foo constructor                 vs   func  func       try   foo             catch          will catch exceptions thrown from foo constructor

User · Answer

The only time you would NOT throw exceptions from constructors is if your project has a rule against using exceptions  for instance  Google doesn t like exceptions   In that case  you wouldn t want to use exceptions in your constructor any more than anywhere else  and you d have to have an init method of some sort instead

User · Answer

Adding to all the answers here  I thought to mention  a very specific reason scenario where you might want to prefer to throw the exception from the class s Init method and not from the Ctor  which off course is the preferred and more common approach    I will mention in advance that this example  scenario  assumes that you don t use  smart pointers   i e - std  unique ptr  for your class  s pointer s  data members   So to the point  In case  you wish that the Dtor of your class will  take action  when you invoke it after  for this case  you catch the exception that your Init   method threw - you MUST not throw the exception from the Ctor  cause a Dtor invocation for Ctor s are NOT invoked on  half-baked  objects    See the below example to demonstrate my point    include  lt iostream gt   using namespace std   class A       public      A int a            m a a                cout  lt  lt   A  A - setting m a to    lt  lt  m a  lt  lt  endl              A                 cout  lt  lt   A   A   lt  lt  endl             int m a      class B   public      B int b            m b b                cout  lt  lt   B  B - setting m b to    lt  lt  m b  lt  lt  endl              B                 cout  lt  lt   B   B   lt  lt  endl             int m b      class C   public      C int a  int b  const string amp  str            m a nullptr            m b nullptr            m str str                m a   new A a           cout  lt  lt   C  C - setting m a to a newly A object created on the heap  address     lt  lt  m a  lt  lt  endl          if  b    0                        throw exception  sample exception to simulate situation where m b was not fully initialized in class C ctor                       m b   new B b           cout  lt  lt   C  C - setting m b to a newly B object created on the heap  address     lt  lt  m b  lt  lt  endl              C                 delete m a          delete m b          cout  lt  lt   C   C   lt  lt  endl             A  m a      B  m b      string m str      class D   public      D             m a nullptr            m b nullptr                cout  lt  lt   D  D   lt  lt  endl             void InitD int a  int b                cout  lt  lt   D  InitD   lt  lt  endl          m a   new A a           throw exception  sample exception to simulate situation where m b was not fully initialized in class D Init   method            m b   new B b               D                 delete m a          delete m b          cout  lt  lt   D   D   lt  lt  endl             A  m a      B  m b      void item10Usage         cout  lt  lt   item10Usage - start   lt  lt  endl          1  invoke a normal creation of a C object - on the stack        Due to the fact that C s ctor throws an exception - its dtor        won t be invoked when we leave this scope               try                       C c 1  0   str1                      catch  const exception amp  e                        cout  lt  lt   item10Usage - caught an exception when trying to create a C object on the stack    lt  lt  e what    lt  lt  endl                          2  same as in 1  for a heap based C object - the explicit call to            C s dtor  delete pc  won t have any effect     C  pc   0      try               pc   new C 1  0   str2              catch  const exception amp  e                cout  lt  lt   item10Usage - caught an exception while trying to create a new C object on the heap    lt  lt  e what    lt  lt  endl          delete pc     2a                3  Here  on the other hand  the call to delete pd will indeed            invoke D s dtor     D  pd   new D        try               pd- gt InitD 1 0             catch  const exception amp  e                cout  lt  lt   item10Usage - caught an exception while trying to init a D object    lt  lt  e what    lt  lt  endl          delete pd              cout  lt  lt    n  n item10Usage - end   lt  lt  endl     int main int argc  char   argv        cout  lt  lt   main - start   lt  lt  endl      item10Usage        cout  lt  lt    n  n main - end   lt  lt  endl      return 0      I will mention again  that it is not the recommended approach  just wanted to share an additional point of view   Also  as you might have seen from some of the print in the code - it is based on item 10 in the fantastic  More effective C    by Scott Meyers  1st edition

User · Answer

Yes  throwing an exception from the failed constructor is the standard way of doing this  Read this FAQ about Handling a constructor that fails for more information  Having a init   method will also work  but everybody who creates the object of mutex has to remember that init   has to be called  I feel it goes against the RAII principle

User · Answer

If your project generally relies on exceptions to distinguish bad data from good data  then throwing an exception from the constructor is better solution than not throwing  If exception is not thrown  then object is initialized in a zombie state  Such object needs to expose a flag which says whether the object is correct or not  Something like this   class Scaler       public          Scaler double factor                        if  factor    0                                 state   0                            else                                state   1                   factor   factor                                   double ScaleMe double value                        if    state                  throw  Invalid object state                return value    factor                     int IsValid                         return  status                 private          double  factor          int  state       Problem with this approach is on the caller side  Every user of the class would have to do an if before actually using the object  This is a call for bugs - there s nothing simpler than forgetting to test a condition before continuing   In case of throwing an exception from the constructor  entity which constructs the object is supposed to take care of problems immediately  Object consumers down the stream are free to assume that object is 100  operational from the mere fact that they obtained it   This discussion can continue in many directions   For example  using exceptions as a matter of validation is a bad practice  One way to do it is a Try pattern in conjunction with factory class  If you re already using factories  then write two methods   class ScalerFactory       public          Scaler CreateScaler double factor                  int TryCreateScaler double factor  Scaler   scaler               With this solution you can obtain the status flag in-place  as a return value of the factory method  without ever entering the constructor with bad data   Second thing is if you are covering the code with automated tests  In that case every piece of code which uses object which does not throw exceptions would have to be covered with one additional test - whether it acts correctly when IsValid   method returns false  This explains quite well that initializing objects in zombie state is a bad idea

User · Answer

Although I have not worked C   at a professional level  in my opinion  it is OK to throw exceptions from the constructors  I do that if needed  in  Net  Check out this and this link  It might be of your interest

[c++] Throwing exceptions from constructors

Examples related to c++

Examples related to exception

Examples related to constructor

Examples related to throw