Re: [boost] [system][filesystem v3] Question about error_code arguments

Subject: Re: [boost] [system][filesystem v3] Question about error_code arguments
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-10-27 20:32:15

"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:a61d44020910200815kedf3976t6e96a67e2f453271_at_mail.gmail.com...
...
> "Library Support for Hybrid Error Handling (Rev 2)", they are
> concerned about specifying hybrid error handling like this:
>
>     void f(error_code& ec=throws());
>
> They would rather see it specified like this:
>
>     void f(error_code* ec=0);
...

i just wanted to make a proposal on a very related subject (an
expension/generalization of the [system] error_code concept) so i'll post it
here instead of starting a new thread:

one of the 'selling points' of exceptions is that they, unlike error return
codes, cannot be (unintentionally) ignored/forgotten...

well...we could 'smarten' our error codes into error objects that 'complain' if
they were not 'inspected' before they are destroyed...
...the 'complaint' method can be made a matter of policy...assert, throw, log
...

so if we have an error object wrapper like this:

template <class ActualError>
class error
{
public:
  error( ActualError const & actual_error )
    :
    actual_error_( actual_error ),
    inspected_( false )
  {}
  ~error() ( if ( !inspected ) throw actual_error_; )

  operator ActualError & () { inspected_ = true; return actual_error_; }

private:
  ActualError actual_error_;
  bool inspected_;
}

we could trivially modify otherwise throwing-but-void-returning functions to
now return errors wrapped in error<>...then the functions themselves would
always be no-throw and the calling code would decide whether to let errors
become exceptions or inspect the results right after the call...
...some usual cases could be made more readable with standardized global
inspecting functions like:

verify( someFuncThatReturnsError(...) );

that would assert that the call indeed succeeded as expected (and in release
only 'touch' the object to prevent the throw)...

and things like that...

the throwing destructor should be safe in this case because error<>, if used
correctly, should always be a temporary and as such can never be destructed as
a consequence of some other exception being thrown...

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