Re: [Boost-users] how can I return a 'null' smart pointer?

From: Joshua Perry (josh_at_[hidden])
Date: 2008-07-16 18:24:17

--------------------------------------------------
From: "gast128" <gast128_at_[hidden]>
Sent: Wednesday, July 16, 2008 3:25 PM
To: <boost-users_at_[hidden]>
Subject: Re: [Boost-users] how can I return a 'null' smart pointer?

> 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.
>

A function like you mention (maybe vector<OrderPtr> 
Customer::GetUnfulfilledOrders( void ); )  could return an vector or custom 
collection with 0 elements, however with a function like OrderPtr 
Customer::GetOrder(int ordern); to me it feels natural to throw an 
exception.

Sure shared_ptr does have a mechanism for validity checking but if you 
forget to validate it and dereference the pointer then you have an 
exceptional condition on your hands.  Is it easier to check the pointer for 
validity or wrap the block in a try {} catch{}?  Personally I would probably 
have the block in a try-catch already and in the circumstances that we are 
talking about (getting order data for a customer) catching an exception is 
an extremely small amount of overhead.

>> 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 :)

I think Herb's argument for using exceptions instead of error codes is very 
, as he puts it, persuasive.  Isn't a call to find a customer's orders 
coming back with nothing an error that you are signaling with a null 
pointer?  It surely isn't a successful finishing state.