Is "Out of Memory" a recoverable error?

[Sean Kelly]

== Quote from Leandro Lucarella (llucax at gmail.com)'s article
> Walter Bright, el  2 de diciembre a las 04:13 me escribiste:
> > I asked this over on stackoverflow.com to see what people using other languages
> > have to say, as well as the D community. The reason I ask is to see if memory
> > allocation can be allowed in functions marked "nothrow".
> >
> > http://stackoverflow.com/questions/333736/is-out-of-memory-a-recoverable-error
> I think all the things said in this thread makes sense (adding callbacks
> to the garbage collector, adding a way to ask for memory that don't throw
> if the memory can't be allocated), but I think this don't cover all the
> possible scenarios.
> For example, I'm working on a softswitch (unfortunately no in D). Lets say
> we have a really bad moment and all the subscribers want to talk at the
> same time and we don't support that workload. Lets say our memory is
> exhausted and a new call arrive. A new allocation is done somewhere deep
> inside the call logic, so the PRE COLLECT callback is called. No memory
> can be reclaimed, so the GC runs a collection. Still no memory. POST
> COLLECT and CRISIS are called too without success. My softswitch is down,
> I lost all the current calls. This is not good for business. What I really
> wanted to do is to catch the memory error as shallow in the call logic as
> possible and drop only that current call, leaving all the current
> established calls intact.

The same could be said of any unexpected error in such an application.  Assuming
that you're doing call processing in a multithreaded app as opposed to dedicating
a process per call (as in Erlang) then you'll have to use try/catch blocks carefully
to perform the necessary cleanup at each stage, re-throwing exceptions you don't
intend to handle.

> So what can I do? Should I manually check each and every allocation in all
> the call logic? I think that's unacceptable.

Agreed.  The point of exceptions is to avoid the need to verify the result of every
operation and to avoid duplication of recovery code.


Sean