"Stewart, Robert" <Robert.Stewart@sig.com> wrote in message news:DF2E67F3D097004694C8428C70A3FD69046F26151F@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