Nikolai N Fetissov <nikolai-boost <at> fetissov.org> writes:
What is so bad in general about returning uninitialized smart pointers? Is that more costly than throwing an exception? I think it's even the other way around.
I mean, there is even some support for testing a smart pointer for validity built into shared_ptr, so why not use it where appropriate? I think this is approriate, as u write in your email. For example finding customer orders which need not exist in an order table, is not an exceptional case and can be signalled with a NULL ptr.
The only problem with returning a null pointer, or -1, or whatever in case of error is that it's easy to ignore at the calling scope, so the upper layers would not even know the error occurred. Exception, on the other hand, propagates up the stack enforcing more structured error handling. Yes but not handling exceptions is fatal for your applications which can be a good thing if the case would corrupt your system anyway, or a bad thing if no serious bad things happen. If every Space Shuttle would crash on every fault, there would be no new austronauts in the USA.
Sutter has made a guideline for when to use exceptions and when not ("When and How to Use Exceptions", http://www.ddj.org/cpp/184401836). By using this guideline, programmers actually have to deal with two strategies instead of one, not to mention that writing excpetion safe code (without leaks) is very hard. If you get stuck you can always buy his books :) Then again there was someone who wrote that writing exception safe code is hard because dealing with errors is hard. So maybe the problem may be more fundamental.