== Quote from Leandro Lucarella ([EMAIL PROTECTED])'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
