That is not the point. The constructor must clean up after itself, so why should the constructor be an exception to the RAII rule? If the code that uses the class uses raw pointers, and therefore makes it safe by wrapping them in smart pointers, then why should not a constructor do so?
The constructor should not clean up by catching the exceptions and re-throwing them. It should rely on objects destructors--objects used inside the constructor--to clean up. That makes the constructor safe, and thus the class safe.
Catching exceptions to clean up is cumbersome and dangerous--it can lead to many bugs. Plus it's expensive to rethrow an exception.
It is like building blocks. Always use building blocks that clean up after themselves everywhere. A raw pointer does not clean up after itself, therefore it is dangerous. A smart pointer will always clean up if properly used, and is therefore safe to use. Even in constructors where you won't have to catch the exception to clean up by using them.
What would such a scenario be? I cannot think of such a scenario where a smart pointer would catch an exception only to delete its raw pointer. That would be silly, since the destructor would always take care of that.Quote:
I meant that shared pointer implementations also throw exceptions from constructors and call delete p before reraising it. So, since it is a used solution and you're going to mention it, I don't see how it's correct to say it's not recommended. Even if it's not recommended, it's in your opinion only.
And no, it's still not my opinion. Catching and rethrowing exceptions is cumbersome and expensive, and is therefore generally not recommended when there are alternative solutions available. And in 99% of the cases, there are.
Linked to is not the same as new articles created there, which is what I was referring to.Quote:
Who said it wasn't used? People link to it all the time on here.