Re: Allocators and exceptions

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 10 Wrz, 00:43, Simon Wright <simon.j.wri...@mac.com> wrote:

> I'm not sure that I'd be scared, precisely.
>
> If this was a safety-related program I would expect some serious test
> effort, which would probably discover the mistake; or maybe formal
> methods would be appropriate.

Sure. Or even better - forget about dynamic memory and solve these
problems by avoiding them.

> Even then, a safety-related _system_ ought to have some strategy for
> recovering from such a runtime error.

Of course - and imagine that it can recover from the error that caused
the exception. But the problem is with memory leak - how can you
recover from memory leak if you don't have any pointer to the memory
block that was already allocated?

> In any case, why would the runtime system need to guarantee memory
> recovery when it can hardly be expected to recover from the failed
> design that led to the situation in the first place?

Assume that it does recover from the failure that has led to the
exception.
How to recover from the resulting memory leak?

> I don't believe
> there's any sensible recovery action to be taken -- the program's
> state is corrupt already.

Why do you think it is necessarily corrupt?
Just reading to the end of the file causes an exception. Using a
network connection that got broken can cause an exception. In both
cases there is no corruption of the program state and reasonable
recovery (or graceful degradation of the functionality) can be
provided.
How to handle the memory leak?

--
Maciej Sobczak
http://www.msobczak.com/