Subject: Re: [boost] [Exception] Why is there no non-const version of get_error_info?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-08-21 18:29:19
See trunk revision 55707. Thanks for the suggestion.
Reverge Studios, Inc.
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)?
> 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).
> 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.)
> With current code (lack of non-const get_error_info) it is not possible. I
> have to get the vector from exception object. Then add data to the vector
> (this may fail). Then again add vector to the exception object (overwriting
> old vector; this may fail). And in the end throw (if needed).
> Alternatively I could preconstruct vector, reserve space add data to it.
> Then in the end if I will throw the data vector is there for me. However I
> still have to add it to the exception object and this still may fail.
> Adam Badura
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk