CODEWITHSUNDEEP
c++c++11exceptiontry-catch
Peng Zhang
Peng Zhang

Reputation: 3595

Why do we need a function try block?

This is a follow-up question of the post. Please see the end of this question for a definition of "function try block".

Question: If a function try block does not "handle" the exception raised in the constructor, why do we need them after all? Could you give an example taking advantage of function try block?

Considering the following code.

#include <iostream>
#include <new>  
#include <exception>
using namespace std;

struct X {
  int *p;
  X() try : p(new int[10000000000]) {}
  catch (bad_alloc &e) {
    cerr << "exception caught in the constructor: " << e.what() << endl;
  }
};

int main() {
  try {
    X x;
  }
  catch (exception &e){
    cerr << "exception caught outside the constructor: " << e.what() << endl;
  }
  return 0;
}

The output is

exception caught in the constructor: std::bad_alloc exception caught outside the constructor: std::bad_alloc

It seems to me that, no matter what I do in the function try block, the exception is always going to be thrown to the outer scope which calls the constructor, e.g. the X x; in the above code.

Definition of "function try block", excerpted from "C++ Primer 5th."

To handle an exception from a constructor initializer, we must write the constructor as a function try block. A function try block lets us associate a group of catch clauses with the initialization phase of a constructor (or the destruction phase of a destructor) as well as with the constructor’s (or destructor’s) function body.

Upvotes: 2

Views: 311

Answers (2)

Cheers and hth. - Alf
Cheers and hth. - Alf

Reputation: 145457

You're right that the exception is always propagated.

The function try block enables you to catch that exception and e.g. destroy an object passed as argument (maybe this is a smart pointer class?), without introducing an artificial base class.

More generally, it gives you the ability to clean up state changes introduced by the call of the function.

For the case of a constructor:

With the exception propagation destructors are called for all successfully constructed sub-objects, including base class sub-objects (if any).

However, this not completely constructed object's own destructor is not called. The function try block is ideally not a device for doing things that would go in that destructor. The not-completely-created object's own destructor has nothing to do, for its task is to clean up state changes introduced by the constructor body and/or later member function calls, and with a common "rule of zero" design there's no such as yet.

Upvotes: 3

MSalters
MSalters

Reputation: 180303

When a constructor throws, the corresponding destructor doesn't run. That's the reason for the quote in your book : cleanup has to be done by the constructor itself.

But your example shows that the exception propagates. This is necessary since the constructor failed, and therefore no object was created. The calling code should not proceed as if the constructor created an object.

Upvotes: 2

Related Questions