Re: [boost] [function] function wrapping with no exception safetyguarantee

Subject: Re: [boost] [function] function wrapping with no exception safetyguarantee
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-22 07:30:24

Emil Dotchevski wrote:
> On Thu, Oct 21, 2010 at 5:32 PM, Daniel Walker
> <daniel.j.walker_at_[hidden]> wrote:
>
> > I think in the case of function wrappers it helps to make a
> > distinction between what I call a "call precondition" and an
> > "exception safety precondition." A call precondition is a condition
> > that must be met in order to invoke a function. One example
> > would be, as you put it, "there must be a function to invoke;" i.e.
> > the wrapper has to be assigned a target. Here's another example:
> > Imagine we had a remote function wrapper so that remote function
> > calls could be used interchangeable with other wrapped functions.
> > Then a call precondition of the remote function wrapper would be
> > that the remote host is available.
>
> Assuming the remote host could disappear at any moment, this is a bad
> example of precondition because the caller can not guarantee that the
> host will be there by the time the function executes and completes.

+1

> This works well for postcondition example: the postcondition would be
> that if the function returns then the remote host was available and
> performed the task successfully (otherwise you'd get an exception.)

Exactly.  Such a function must account for the variable conditions necessary for it to complete successfully.  The network could be down.  There could be no route to the remote host.  The remote host could be down.  The remote host could be slow to respond.  All of these can lead to a failure that the caller shouldn't be responsible to ensure before being allowed to call the wrapper.  They are runtime conditions the wrapper must handle.  Handling might mean retrying some number of times and then, ultimately returning an error code or throwing an exception.

> > An exception safety precondition applies after a function has been
> > called and is running. And I like your wording, it is "a condition
> > that the caller must satisfy in order for the called function to
> > behave as documented" with respect to exception safety.
>
> If the caller violates a precondition, all bets are off not only wrt
> exception safety (the plane may crash, the patient may overdose.)

Right.  If the caller didn't establish necessary conditions for calling the function, then the function is not responsible for the results.  OTOH, if the caller does meet the preconditions, *everything* else is the responsibility of the called function WRT to documented behavior, including exception guarantees.

In the case of boost::function, having no target *is* a valid state.  Therefore, the function call operator *must* account for that state.  It does so by throwing an exception.  There is no precondition violation when there is no target.

> > I think the reason the distinction is important is that function
> > objects do not normally have call preconditions; i.e. the
> > function is always there, and when operator() is invoked, control
> > is passed to the function.
>
> The function you point to may still have its own preconditions. It
> isn't a good idea to pass control to a function, through a pointer or
> otherwise, unless its preconditions are met.

+1

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.