Re: [boost] [Exception] Why is there no non-const version of get_error_info?

Subject: Re: [boost] [Exception] Why is there no non-const version of get_error_info?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-08-19 18:39:23

On Wed, Aug 19, 2009 at 5:14 AM, Adam Badura<abadura_at_[hidden]> wrote:
>   get_error_info takes a const exception object and returns a pointer to
> const data object of respective error_info. But why is there no way of
> getting non-const pointer (which would allow to modify the data)?

The easy answer is: because I haven't needed to modify the data, and
nobody has requested it before.

Logically, the error info interface is intended for recording various
known facts about an exception object: "What's the name of the file
that failed to open?" "What error code did the OS report?" Etc. etc.
These things aren't mutable.

>   This is especially strange because operator << can be used to add data to
> a const exception object so I don't see reason for not being able to get
> modifiable data back (at least from non-const exception object).

Adding error info is supported for const exceptions because it isn't
stored in the exception object itself, it's stored in a separate
object the exception points to. This arrangement can't be just an
implementation detail because the copy constructor is required to be
nothrow.

The other reason is to support the throw foo() << my_Info() syntax.

>   Having this would allow me to safely gather exception data before throwing
> or during exception propagation. What I wanted was to insert an empty vector
> of data to the preconstructed exception object. Then obtain the vector with
> get_error_info (since operator << adds a copy I have to get the actual
> object). Then call reserve on the obtained vector and start the actual
> operation. During the operation I can gather (possible) error data and
> safely add it to the vector since memory is already reserved. In the end if
> any error data was gathered I will throw the preconstructed exception
> object. In reasonable implementation this should be safe as well.
>   (Similar thing might be done while propagating the exception.)

I'm curious, could you post more information about your use case?
What's this vector, what kind of objects/info does it store? I'm not
against your request, but I want to understand your motivation better.

(Also note that a failure to add error info to an exception is not the
end of the world, the system is exception-safe.)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode