Is "Out of Memory" a recoverable error?

[Sean Kelly]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> Robert Jacques wrote:
> > Okay, while we've been talking about OutOfMemoryError there's also
> > RangeError, AssertError, FinalizeError and SwitchError and not allowing
> > array indexing, contract programming or switches inside a nothrow
> > function drastically reduces their usefulness (more so than allocation,
> > in my opinion). So at least in debug mode, the handling frame (I think)
> > exists in order to support RangeError and AssertError errors. However,
> > SwitchError and HiddenFuncError occur in release code, so I'm not sure
> > if nothrow functions will not have some error handling method. (I think
> > FinalizeError is related to allocation and therefore OutOfMemoryError)
> The idea behind Errors is that, even if you catch the exception,
> unwinding may not occur. Thus, your app should not be relying on
> destructors cleaning up properly. Catching an Error should only be used
> for doing things necessary before shutting down the app.

I disagree.  D is a systems app and so should not require termination on
any error.  The distinction to me is that Errors require special handling
if recovery is to be attempted, while it's often safe (if bad practice) to
simply log Exceptions and soldier on.  That isn't to say that it's always
possible (and certainly not always advisable) to recover from an Error,
but I think that decision should be left up to the user.


Sean