昨天我在参与讨论的SO致力于OutOfMemoryException异常和处理它的利弊（的 C＃中的try {}赶上{} ）。

Yesterday I took part in a discussion on SO devoted to OutOfMemoryException and the pros and cons of handling it (C# try {} catch {}).

我的优点来处理它是：

在这OutOfMemoryException异常被抛出的事实，一般不意味着一个程序的状态被破坏; 据文件下面的Microsoft中间（MSIL）指令抛出OutOfMemoryException异常：彩盒，newarr，newobj这只是（通常情况下）是指在CLR试图找到一个给定大小的内存块，是无法做到这一点;它的没有的意思是，没有任何一个字节留在我们的性格; The fact that OutOfMemoryException was thrown doesn't generally mean that the state of a program was corrupted; According to documentation "the following Microsoft intermediate (MSIL) instructions throw OutOfMemoryException: box, newarr, newobj" which just (usually) means that the CLR attempted to find a block of memory of a given size and was unable to do that; it does not mean that no single byte left at our disposition;

不过，并不是所有的人都认同这一点，这个异常以及无法做一些有用的东西，因为它需要更多的内存后推测未知程序的状态。

But not all people were agree with that and speculated about unknown program state after this exception and an inability to do something useful since it will require even more memory.

所以我的问题是：什么是重大理由不办理OutOfMemoryException异常，并立即当它发生时放弃

Therefore my question is: what are the serious reasons not to handle OutOfMemoryException and immediately give up when it occurs?

编辑：你认为OOME是致命的ExecutionEngineException

Edited: Do you think that OOME is as fatal as ExecutionEngineException?

推荐答案

我们都编写不同的应用程序。在一个WinForms和ASP.Net应用程序，我想可能只是记录异常，通知用户，尽量节省状态，关机/重启。但作为伊戈尔评价提到这很可能是从建立某种形式的图像编辑应用程序和加载第一百20MB RAW图像可能推过边缘的应用程序的过程。你真的想利用从一些简单的话说，失去所有的工作。 对不起，无法加载更多的图像在这个时候。

We all write different applications. In a WinForms or ASP.Net app I would probably just log the exception, notify the user, try to save state, and shutdown/restart. But as Igor mentioned in the comments this could very well be from building some form of image editing application and the process of loading the 100th 20MB RAW image could push the app over the edge. Do you really want the use to lose all of their work from something as simple as saying. "Sorry, unable to load more images at this time".

另一种常见的情况下，它可能是有用的追赶内存不足异常是在后端批量处理。你可以有加载多兆字节的文件到内存中进行处理的标准模型，但后来有一天出了多千兆字节的文件被加载的蓝色。当内存不足外发生时，你可以将消息记录到用户通知队列，然后移动到下一个文件。

Another common instance that it could be useful to catch out of memory exceptions is in back end batch processing. You could have a standard model of loading multi-mega-byte files into memory for processing, but then one day out of the blue a multi-giga-byte file is loaded. When the out-of-memory occurs you could log the message to a user notification queue and then move on to the next file.

是的，它有可能是别的东西可以打击的同时，但这些也将被记录，如果可能的话通知。如果最后GC不能处理任何更多的内存的应用程序要往下走难呢。 （GC的运行在无保护的线程。）

Yes it is possible that something else could blow at the same time, but those too would be logged and notified if possible. If finally the GC is unable to process any more memory the application is going to go down hard anyway. (The GC runs in an unprotected thread.)

不要忘了，我们都开发出不同类型的应用程序。除非你是旧的，有限的机器，你可能永远不会得到一个OutOfMemoryException为典型的商业应用程序......但话又说回来我们不是所有的都是商业工具的开发者。

Don't forget we all develop different types of applications. And unless you are on older, constrained machines you will probably never get an OutOfMemoryException for typical business apps... but then again not all of us are business tool developers.

您的编辑......

Out的内存可以通过非托管内存碎片和压引起的。它也可以由大分配请求引起的。如果我们要竖起白旗，并绘制在沙地上这么简单的问题行，没有什么会永远得到大型数据处理项目完成。现在比较这致命引擎异常，也有你可以在运行时倒下死点在你的code无能为力。希望你能够登录（但可能不会）为什么你的code落到它的脸上，所以你可以prevent它的未来。但是，更重要的是，希望您code被写入的方式，可以允许的尽可能多的数据安全恢复，你可以。甚至恢复最后一次正确的状态下，在您的应用程序，并可能跳过违规破坏数据，并允许它被人工处理和回收。

Out-of-memory may be caused by unmanaged memory fragmentation and pinning. It can also be caused by large allocation requests. If we were to put up a white flag and draw a line in the sand over such simple issues, nothing would ever get done in large data processing projects. Now comparing that to a fatal Engine exception, well there is nothing you can do at the point the runtime falls over dead under your code. Hopefully you are able to log (but probably not) why your code fell on its face so you can prevent it in the future. But, more importantly, hopefully your code is written in a manner that could allow for safe recovery of as much data as you can. Maybe even recover the last known good state in your application and possibly skip the offending corrupt data and allow it to be manually processed and recovered.

然而，在同一时间它只是作为可能有造成SQL注入的数据损坏，失同步的软件，指针操作，缓冲液中运行等诸多问题的版本。避免只因为你的问题想的你的不可以的追讨这是一个伟大的方式提供给用户的错误消息，因为有建设性的的请与系统管理员联系。

Yet at the same time it is just as possible to have data corruption caused by SQL injection, out-of-sync versions of software, pointer manipulation, buffer over runs, and many other problems. Avoiding an issue just because you think you may not recover from it is a great way to give users error messages as constructive as Please contact your system administrator.