问题描述

我正在编写代码来捕获这个 OutOfMemoryException 并抛出一个新的、更直观的异常:

I am writing code that catches this OutOfMemoryException and throws a new, more intuitive exception:

/// ...
/// <exception cref="FormatException">The file does not have a valid image format.</exception>
public static Image OpenImage( string filename )
{
    try
    {
        return Image.FromFile( filename );
    }
    catch( OutOfMemoryException ex )
    {
        throw new FormatException( "The file does not have a valid image format.", ex );
    }
}

用户是否可以接受此代码，还是出于特定原因故意抛出 OutOfMemoryException?

Is this code acceptable to its user, or is OutOfMemoryException intentionally being thrown for a particular reason?

推荐答案

不，这是历史.GDI+ 是在 .NET 出现之前很久才编写的.它的 SDK 包装器是用 C++ 编写的.C++ 中的例外是不确定的，并不是每个人都接受它们.例如，谷歌没有.因此，为了保持兼容，它会报告错误代码的问题.这永远不会很好地扩展，库程序员将故意限制可能的错误代码的数量作为目标，它减轻了客户端程序员必须报告它们的负担.

No, it is history. GDI+ was written quite a while before .NET ever came around. The SDK wrapper for it was written in C++. Exceptions are iffy in C++, not everybody buys into them. Google doesn't for example. So to keep it compatible it reports problems with error codes. That just never scales well, library programmers make it a goal to intentionally limit the number of possible error codes, it lessen the burden on the client programmer having to report them.

GDI+ 有这个问题，它只定义了 20 个错误代码.对于具有如此多外部依赖项的如此大块代码来说，这并不.这本身就是一个问题，有无数种方法可以弄乱图像文件.库的错误报告不可能细化到足以涵盖所有这些.早在 .NET 定义标准异常派生类型之前就选择了这些错误代码这一事实当然没有帮助.

GDI+ has this problem in spades, it defines only 20 error codes. That is not much for such a large chunk of code with so many external dependencies. Which in itself is a problem, there are a gazillion ways to mess up an image file. No way that a library's error reporting can be fine-grained enough to cover them all. The fact that these error codes were picked long before .NET defined standard Exception derived types certainly didn't help.

Status::OutOfMemory 错误代码被重载以表示不同的含义.有时它确实意味着内存不足，它无法分配足够的空间来存储位图位.可悲的是，相同的错误代码报告了图像文件格式问题.这里的摩擦是它不可能确定它从图像文件中读取的宽度 * 高度 * 像素是否有问题，因为没有足够的存储空间可用于位图.或者如果图像文件中的数据是垃圾.它假定图像文件不是垃圾，公平调用，这是另一个程序的问题.所以 OOM 就是它报告的内容.

The Status::OutOfMemory error code got overloaded to mean different things. Sometimes it really does mean out of memory, it can't allocate enough space to store the bitmap bits. Sadly, an image file format problem is reported by the same error code. The friction here is that it cannot possibly decide if the width * height * pixels it read from the image file is a problem because there isn't enough storage available for the bitmap. Or if the data in the image file is junk. It assumes that image file is not junk, fair call, that's another program's problem. So OOM is what it reports.

为了完整起见，以下是错误代码:

For completeness, these are the error codes:

enum Status
{
    Ok = 0,
    GenericError = 1,
    InvalidParameter = 2,
    OutOfMemory = 3,
    ObjectBusy = 4,
    InsufficientBuffer = 5,
    NotImplemented = 6,
    Win32Error = 7,
    WrongState = 8,
    Aborted = 9,
    FileNotFound = 10,
    ValueOverflow = 11,
    AccessDenied = 12,
    UnknownImageFormat = 13,
    FontFamilyNotFound = 14,
    FontStyleNotFound = 15,
    NotTrueTypeFont = 16,
    UnsupportedGdiplusVersion = 17,
    GdiplusNotInitialized = 18,
    PropertyNotFound = 19,
    PropertyNotSupported = 20,
#if (GDIPVER >= 0x0110)
    ProfileNotFound = 21,
#endif //(GDIPVER >= 0x0110)
};