Re: [boost] [Exception] Why is there no non-const versionofget_error_info?

Subject: Re: [boost] [Exception] Why is there no non-const versionofget_error_info?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-08-20 18:29:07

On Thu, Aug 20, 2009 at 2:59 PM, Adam Badura<abadura_at_[hidden]> wrote:
>   Taking into account our previous discussions I expected that you will
> rather try to convince me that what I was going to do is bad rather then try
> to add non-const get_error_info. :)

The reputation I got, Jesus. :)

>> Alternatively, you can collect them all into a
>> std::vector<boost::exception_ptr>. When you're done calling onNotifys,
>> if the vector is not empty you just throw an exception, adding the
>> vector to it.
>>
>> If you are concerned about the (remote?) possibility of a
>> std::bad_alloc propagating instead of your exceptions, you shouldn't
>> be because that could happen anyway. To throw an exceptoin, the
>> runtime needs memory to store the exception object. In some
>> implementations that memory comes from the heap, so an attempt to
>> throw any exception whatsoever could result in a std::bad_alloc
>> instead (the runtime is required to have enough memory to throw a
>> std::bad_alloc.)
>
>   Yes. I described that method as an alternative. And yes I am concerned
> with risk of std::bad_alloc. And yes I cannot avoid it fully anyway. But
> Boost exceptions objects are small so the risk is marginal. And if this
> happens anyway then I consider it an error so fatal that I will not recover
> from it anyway - just unwind the stack. Just because you cannot avoid
> accident does not meant that you will put yourself to an unnecessary risk,
> right?

Are you sure the reserve() will reduce the risk significantly? Note
that boost::exception_ptr itself also allocates memory, not to mention
the onNotify functions themselves, assuming they aren't trivial they
could be allocating things as well.

>   Want another example? What about stack trace? I could have a sequence
> container in the exception and in each catch in which I will rethrow the
> exception I would add source code location data to have better diagnostic
> information. Obviously I cannot do this with fixed number of separate
> error_infos (without loss of data).

Yes that's a good one though the stack trace should be captured in one
go before you throw. The trouble is this isn't possible in a
platform-independent way; I'm hoping someone will come up with
platform-specific implementation. I will add this support as soon as
it's available, I do believe it is a very valuable diagnostic tool.

>   But I will not only defend myself but rather strike back now! :) (Keep in
> mind it is a joke!)
>   What are the reasons to not have non-const get_error_info? I haven't look
> into implementation but I guess it requires almost no work at all to add
> (and maintain) it.

In fact yesterday I went ahead and implemented it on my system, seems
fine. I'll do some more testing and I'll commit it to trunk soon.

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