throw-expression is of type void actually (see 15/1). What happens is special treatment of throw-expression in conditional-expression as per 5.16/2. I don’t think this is that academic but rather to save some typing and have:

int y = x > 4 ? x : throw std::out_of_range (“”) ;

instead of:

int y = x > 4 ? x : (throw std::out_of_range (“”), 0) ;

which still would be necessary if you decide to call void-returning function instead of raising an exception.

open(FOO,$foo) || die "Can't open $foo: $!";

SomeClass* ptr = foobar->Baz || throw “Failed!”;

Try this link for questions about destruction in partially constructed objects:

http://stackoverflow.com/questions/188693/is-the-destructor-called-if-the-constructor-throws-an-exception/188882

What’s happen in constructors/destructor is usually easy to understand (even if it can get confused when dealing with multiple inheritance). The order of member variables construction/destruction is known (i.e. the order of their declaration in the class/struct, or its exact reverse for destruction).

The “do nothing in constructor/destructor” is a pattern usually seen in C coders who came to C++, and of course, it is a wrong pattern.

I do not agree (with almost 20 years of experience in the language).

Constructors and destructors are two of the most dangerous places in the language – because tons of “invisible code” is called, constructors of parts or of parents that’s not represented in code at all but created by the compiler.

There are a lot of arcane details there, relating for example to the creation and destruction order (particularly of static objects). Best to not even have to think about it.

As a rule, I do as absolutely little as possible in an object’s constructor. This rule usefully applies to every language I write in, it seems! (Well… it seems less important in Python, but then everything there seems really light anyway…)

If you need to validate parameters, do that in a factory function. Factory functions have a lot of advantages over C++ constructors anyway: you can have multiple factory functions with the same signature, you can give them self-documenting names, and most important, they’re easy to mock where constructors cannot be.

In general, it’s a bad idea to do something that might confuse the next person without a really good reason. When I’m debugging a system that’s displaying unusual behavior, if I see

RangeChecked::RangeChecked(int x) : int_member(x > 0 ? x : throw std::out_of_range) {}

I immediately spend a few minutes thinking it through and probably searching the documentation. And I’d worry in the back of my head that this might not work under a different compiler.

Even a comment would require me to read it and ask myself if I really believed it.

It’s a small cognitive load on each later programmer – for zero benefit. Keep it simple!

I disagree that exceptions shouldn’t be thrown from constructors, and take the view that exceptions are the best way to signal constructor failure. Each member that has already been constructed should have its destructor called, so it is not an issue, unless the data members are unmanaged, which is usually bad practice anyway.

It doesn’t make sense for the destructor to be called on a partially constructed object, which is why the destructor will never be run unless the constructor ran to completion. If any manual cleanup is needed, it can be handled, even from a exception originating in the constructor initializer list, by use of a function-try block, but at that point any concision gained by not moving checking into the constructor body and assigning to the data members has probably been lost.

Another approach is the one Haskell takes, where the throw, and the context is operating inside a monad, but it is farther away from the C++ semantics.