Re: [boost] [function] function wrapping with no exceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping with no exceptionsafetyguarantee
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-10-23 01:44:45

On 10/22/2010 1:35 PM, Daniel Walker wrote:
> On Thu, Oct 21, 2010 at 7:05 PM, Daniel Walker
> <daniel.j.walker_at_[hidden]>  wrote:
>> On Thu, Oct 21, 2010 at 6:13 PM, Edward Diener<eldiener_at_[hidden]>  wrote:
>>> On 10/21/2010 6:05 PM, Daniel Walker wrote:
>>>> Right. I don't mean the management system has a bug, I mean that it
>>>> has encountered a problem, for example, cloning the target. So,
>>>> boost::function could be empty because it has never been assigned a
>>>> target or because the most recent attempt to assign a target failed...
>>>> or because it was cleared by the user calling clear(). Are those all
>>>> of the scenarios that can lead to an empty boost::function?
>>>
>>> I don't mean to question the design of boost::function but wouldn't the
>>> inability of cloning a target, or assign a target, be a problem which should
>>> lead to an exception being thrown ?
>>
>> Right, but suppose boost::function was instantiated outside of the try
>> block where the assignment fails. Then after the exception is thrown
>> and handled, the boost::function object could still be used.
>>
>> But actually, I just noticed that, even though the portable function
>> wrappers are empty after an assignment failure, boost::function is not
>> actually cleared. So, in fact, a failed assignment is NOT a scenario
>> that leads to an empty state, as I first thought. This is probably an
>> oversight/bug in the portable wrappers, right?
>>
>>>
>>> I would assume that boost::function not having a target would normally only
>>> occur if no target had been set or if the user removed a target which had
>>> been set.
>>
>> Right, and indeed, this appears to be the case... unless there's some
>> other scenario we overlooked...
>
> Oops. Sorry, I spoke too soon. In fact, it IS currently possible for a
> boost::function object to become empty due to a failed assignment. It
> happens because the small object manager clones the target during a
> call to swap(). If there is an exception during the allocation,
> boost::function handles it, sets itself to empty and rethrows.

That's understandable. Once an exception is thrown its the end-user's 
responsibility to deal with the end result.

I do not understand why others are upset that invoking boost::function 
on an empty target should throw an exception. It is equivalent in my 
mind to calling a function through a function pointer which is null.