Re: Fw: Re:[v3] system_error, round one

[Benjamin Kosnik <bkoz at redhat dot com>]

 Didier wrote:
> Ah yes, it seems N2066 is flawed on this point.
> I suppose you refer to:
>
> >      private:
> >        string what_msg; // for exposition only
>
> and then:
>
> > const char * what() const;
> >
> > Returns: If !code() || !append_message(), return 
> > this->runtime_error::what(). Otherwise, as if:
> >    what_msg = this->runtime_error::what();
> >    if ( !what_msg.empty() ) what_msg += ": ";
> >         what_msg += code().message();
> >    return what_msg.c_str();

Yep.

> Generally speaking, the idea of embedding a std::string into an 
> exception object
> sounds questionable to me. Can't a string constructor throw itself an 
> exception?
> On the other hand, I don't see many solutions ...

We've tried other solutions in the past, with char arrays. These seem to 
have the downside of implementation-defined limits on string length. No 
matter how big we make them, it seems as if some user runs into the wall...

> If a std::string member must really be used, perhaps you could tag it as 
> mutable?

Yes, that is an option. I will also have to make it protected, though....

However, this specification is assuming or adding new functionality to 
exceptions, as originally designed.

Instead, I'm reviewing error handling in totality, along with Jason's 
patch for iostreams vs. cancellation. It would be nice to come up with 
something that is simple, consistent, and more capable, especially since 
this error handling stuff is already being added.

-benjamin