Steven Schveighoffer wrote:
It can be. For example, if you want to allocate a gigantic buffer to see if you can load a file, you may catch for failure, and display an appropriate message to the user on failure. The application could still continue to run. I think the difference between recoverable and non-recoverable is the size of the allocation. If the size is sufficiently large enough, you can still have memory to deal with the failure. If allocating 16 bytes gives you a failure, then may not be able to do much to get around it.
I should point out that in such cases (probing a large allocation), the error recovery is very local. I.e. there's no need for throwing an exception and then recovering in some arbitrary user code way up the stack.
In most cases, an out of memory failure is a non-recoverable error. My thoughts are, add a recoverable allocate function to the GC. If one wants a recoverable memory error, he must call that function to allocate. Don't allow that function in nothrow functions, but allow standard (non recoverable) memory allocation to be called.
I think this may be the best strategy.