Re: [boost] [system][filesystem v3] Questionabout error_codearguments

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
>news:DF2E67F3D097004694C8428C70A3FD69046F26151F_at_msgbal516.ds.susq.com...
> 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 decide...in 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 
debugging)...

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

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