Re: [boost] [system][filesystem v3] Questionabouterror_codearguments

Subject: Re: [boost] [system][filesystem v3] Questionabouterror_codearguments
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-07 12:07:50

"Gottlob Frege" <gottlobfrege_at_[hidden]> wrote in message 
news:97ffb310911020958y7815771dpfc7686ebc03e4071_at_mail.gmail.com...
On Sun, Nov 1, 2009 at 6:03 PM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>bool copy(file dest, file src)
>{
>   error_code errSrc = open(src);
>   error_code errDst = create(dest);
>
>   if (errSrc || errDst)
>      return false;
>
>   //copy...
>   return true;
>}
>
>In this case, we are not throwing during exception unwinding, but if
>errSrc is true, errDst is NOT checked, and thus throws.  Should it?

"oh darn" just when i thought a real world usage was found for 
std::uncaught_exception() (as an answer to gotw-047 question #3 :) ...
...well maybe it's still valid but it does not help us in this case...
...however the other proposed soultion (with "temporary error code" 
inaccessible to the user) would, as far as i can see, solve this problem 
also...
...if it were not for c++1x auto...which quite elegantly allows the user to 
unintentionally "shoot him/herself in the foot" in this particular case...
...as i'm not an expert on the upcoming standard (and the auto proposal) maybe 
someone smarter knows how (if anyhow possible) to circumvent this issue/disable 
auto declarations for certain types that you want to remain hidden from the 
user...?

>I think, at best, a smart_err_code should just assert() in debug only.
> ie check to make sure errors are being checked -> ie check for
>programmer error.

as explained in a previous post, yes this is the basic usage/idea for a 
"smarter error code"...
...a separate problem is whether the "smarter error code" idea/design can be 
expanded/"smartened further" to provide a better/best possible solution for the 
error codes vs exceptions problem/dillema...

>As for throwing or not, lean towards throwing, supply both when there
>is good reason.

the problem is that this only shifts the discussion onto the topic "what is 
good reason" (in this case)...;)

>I think throwing needs to become more common, particularly with
>multi-threading, because you can't necessarily check pre-conditions
>anymore - the preconditions might not last long enough for the
>function call. Even for file functions:
>
>if (!exists(file)) // check precondition
>   create(file);   // yet this throws "already exists"

this actually an old general multi-tasking (not just multithreading) 
issue...and exceptions do not help you there (what should throw in this case, 
exists(), create() or both?)...because its just wrong to do it that way...
you call create() directly and then inspect the result as to see what actually 
happened (be it explicitly or implicitly, with error codes or exceptions)...

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