Long-standing error in exception handling by pool_allocator (contains untested patch)

[Joachim Kuebart]

On Sat, Oct 09, 2004 at 11:40:01PM +0200, Paolo Carlini wrote:
> Joachim Kuebart wrote:
> >>2- I think we should catch only std::bad_alloc, not all the possible 
> >>exceptions.
> >>   
> >>
> >This should work and might be correct, however it seems to me that the rest
> >of the library uses catch (...) throughout. I wonder why?
>
> Yes, I also wonder why... ;) I mean: in some places we *really* want to 
> catch
> everything (e.g., istream, ostream); in other places, we are actually 
> *just* dealing
> with std::bad_alloc, in order to avoid memory leaks. Probably, we should 
> think
> more about the latter... anyway, I agree that this is an unrelated issue...

It could be argued that "malicious" code, in this case an ::operator new()
throwing a different exception than bad_alloc, should not be allowed to break
the allocator's integrity. This would be the case for an uncaught exception
and therefore, it is necessary to catch all exceptions.

Maybe exceptions other than bad_alloc should be treated differently in that
they should not trigger any actions and should be re-thrown after ensuring
that internal integrity is maintained.

Just my 2c...

cu Jo

-- 
La perfection est atteinte non quand il ne reste rien à ajouter, mais quand
il ne reste rien à enlever.  (Antoine de Saint-Exupéry)