Re: [boost] [system] Undocumented deprecated throws variable +run-time error

20 Oct 2010

      Hrrr,
----- Original Message ----- 
From: "vicente.botet" <vicente.botet@wanadoo.fr>
To: <boost@lists.boost.org>
Sent: Wednesday, October 20, 2010 1:33 AM
Subject: Re: [boost] [system] Undocumented deprecated throws variable +run-time error
...
----- Original Message ----- 
From: "vicente.botet" <vicente.botet@wanadoo.fr>
To: <boost@lists.boost.org>
Sent: Tuesday, October 19, 2010 9:16 PM
Subject: [boost] [system] Undocumented deprecated throws variable
Hi Beman,
The documentation doesn't states explicitly that the throws variable is deprecated (see section "Deprecated names"). In addition the section "Semantics of throws object" explaining how this variable should be used must be rewritten to show the usage of the function throws().
Could this be changed for 1.45?
_____________________
More in the throws() function.
In principle, when I check if an error_code is the throws error_code I'm doing like follows
void f(system::error_code& ec) {
   ...
   if (&ec == &boost::throws()) {
       // throw an exception
   } else {
       // update the ec
   }
}
When I do that I get run-time errors.
I have changed the throws function so instead of returning a 0 returns a pointer to a static variable and check that the value of the variable don't change. Then all works again.
namespace detail { 
     inline system::error_code * throws() { 
#if 1          
       static system::error_code throws_(0x1234, system::generic_category());
       assert(
           (throws_.value()==0x1234) 
       && 
           (&throws_.category()==&system::generic_category()));
       return &throws_;
#else          
       return 0; 
#endif          
     } 
 }
   //  Misuse of the error_code object is turned into a noisy failure by
   //  poisoning the reference. This particular implementation doesn't
   //  produce warnings or errors from popular compilers, is very efficient
   //  (as determined by inspecting generated code), and does not suffer
   //  from order of initialization problems. In practice, it also seems
   //  cause user function error handling implementation errors to be detected
   //  very early in the development cycle.
 inline system::error_code & throws()
   { return *detail::throws(); }
Am I doing something wrong?
I send the post too early. I dis a bad test. And now I can see that I was updating the throws() storage in some cases.

Thanks Beman for the trap.

Best,
Vicente