http://ideone.com/UtVzxw
struct base
{
base() { throw std::exception(); }
};
struct derived : public base
{
derived() try : base() { }
catch (
function-try-block in the constructor doesn't prevent the exception from being thrown. Here's an excerpt from C++ standard draft N4140, [except.handle]:
14
If a return statement appears in a handler of the function-try-block of a constructor, the program is ill-formed.
15
The currently handled exception is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor. Otherwise, ...
The reason for this is that if base class or any member constructor throws an exception, then the construction of the whole object fails, and there's no way to fix it, so the exception has to be thrown.
There's a GOTW on this, and the bottomline is
Constructor function-try-block handlers have only one purpose -- to translate an exception. (And maybe to do logging or some other side effects.) They are not useful for any other purpose.
So, yes, your last code sample is perfectly fine.
Wrapping a try/catch around a superclass's constructor lets you trap exceptions that get thrown in the superclass's constructor; however the exception gets automatically rethrown when the catch
block ends, and the exception continues to propagate.
After all, the superclass did not get constructed. It threw an exception. So you can't really continue on your merry way, in the subclass's constructor, and then end up with a constructed subclass, but with a superclass that did not get constructed. That makes no sense.
From http://en.cppreference.com/w/cpp/language/function-try-block:
The primary purpose of function-try-blocks is to log or modify, and then rethrow the exceptions thrown from the member initializer list in a constructor. They are rarely used with destructors or with regular functions.
This is really the primary value-added of function-try blocks: a convenient place to log "hey, this function threw an exception", that encompasses the entire function, a single place to log this kind of a thing, but without affecting ordinary exception handling.