Boost logo

Boost :

Subject: Re: [boost] [system][filesystem v3] Questionabout error_codearguments
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-01 17:29:58

>"Stewart, Robert" <Robert.Stewart_at_[hidden]> wrote in message
> Domagoj Saric wrote:
>> ..._only_ if you save the returned object into a local scoped
>> variable _and_ do
>> not inspect it can the issues of "library after throw" and
>> "abort on exception
>> in destructor during unwind" come into play...
> The complexity of this magical behavior

did you have anything other in mind (besides the issues below)?

>From a debugging perspective, the exception will be thrown at the wrong point.
> the problem with throwing in the caller rather than at the point of error
(i merged these two statements as they seem to state the same/similar point)

i'd say the 'debugging perspective' is here actually in the 'eye of the
beholder' (i.e. up to the user to the sense that a function/library
that uses the 'smart_error<>'
approach has automatically given up the decision on what constitutes an
exceptional situation/error/state and left that up to the user...and the
interpretation of 'correctness' of that, again, depends on the perspective: if
you value configurability more, it's a good thing, if you value 'paranoia'
more, it's a bad thing...and so on...)
...the situation is the same as with existing os/crt/extern "c" functions that
only return errors that you inspect and (sometimes) convert to
exceptions...when such an exception is thrown at the error inspection site
would you say that it was thrown at the wrong point (at the point of result
code inspection instead of from within the function that returned the error)..?
you still have the information which function call produced the error...if it
is somehow critical that you know the exact source line at which the error was
produced (within the function that you would rather to throw):
- the debugger can be instructed to break at points of smart_error<>
construction when the status_code with which it is constructed is different
from some "error_success" value...
- the function in question can save the __FILE__ and __LINE__ information into
the returned smart_error<> object
- the particular "smart_error<>" class can be "instructed" to assert or call
_CrtDbgBreak when constructed with a non-success "actual_error" (when

> the overhead of checking to see whether to throw at each call site,

there are ways that this can be minimized (or in some cases eliminated):
- move the exception object construction and the throw statement into a
separate (preferably nontemplated) function marked as noninline
- now we are left with an { if (!inspected && !succeded) do_throw() } which
would/could probably translate to 5-6 cisc instructions
- if the returned error object is imediately inspected after the function
returns (as is the intended use) it is 'plain obvious' to the compiler that
those "remaining instructions" are redundant and would be removed completely...
- if, on the other hand, the returned error/status object is left uninspected,
to throw if an error has occured, the only thing i see that could be done is
somehow make it safe for the compiler to assume that the value of 'inspected'
is always false right after exiting from the function (which should/must always
be the case for correctly constructed error<> objects...right 'in' the return
statement)...then we'd be left with a single if (!succeded) do_throw()...which
is pretty much the same as in a usuall approach of converting an error code
into an exception...and thus putting this case in a "grey"/"your mileage may
vary" area...depends on particular use cases what would produce better code...

> and the danger of throwing in the destructor during stack unwinding,

we seem to be "running in circles"...(afaik) there is no such danger for
temporary objects...

> makes overloading each affected function a pleasant alternative.

sorry i still don't see either of the presented options as a 'clear win

and what exactly do you mean under "affected function"?

 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley 

Boost list run by bdawes at, gregod at, cpdaniel at, john at