Andrew Mellinger
This throwing c++ constructor stuff is btw the way to transport errors according to a lot of c++ gurus. But my persnonal opinion is that it sucks. Every created object must be guarded with exception safety.
I don't know what "guarded with exception safety" means. You certainly don't need try/catch blocks everywhere.
For large applications, this exception mecahnism is very tricky and sources for a lot unwanted application terminations or memory leaks.
Writing exception-safe code is not really any harder than writing code that's correct in the presence of errors with any other error-reporting mechanism. In fact, given a clear understanding of how to use exceptions effectively, they are less tricky to use correctly than other approaches to error handling, because they provide a high-level abstraction that lets you concentrate on what matters.
I agree. At my workplace we have a convention. For heavyweight objects that would do interesting things in their constructors we instead use the alloc-init paradigm of Objective-C. In this model, the constructor does simply non-error things, then a corresponding init (or even suite of init methods) does the interesting things. This has the added benefit that the init method can be overridden in subclasses, and you don't need to re-implement all the behaviors.
The alloc-init paradigm _really_ sucks. Instead of considering exceptions in your constructors you end up having to guard all the rest of the code with "what if this object failed its initialization?" checks/handlers. -- Dave Abrahams Boost Consulting www.boost-consulting.com