我正在编写捕获此问题OutOfMemoryException并引发新的,更直观的异常的代码:
OutOfMemoryException
/// ... /// <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由于特定原因而有意抛出?
不,这是历史。在.NET出现之前,就已经编写了GDI +一段时间。它的SDK包装器是用C 编写的。在C 中,异常是很容易的,并不是每个人都认可它们。谷歌没有。因此,为了使其兼容,它会报告错误代码问题。这永远无法很好地扩展,库程序员将故意限制可能的错误代码的数量作为目标,这减轻了客户端程序员必须报告错误代码的负担。
GDI +冒犯了这个问题,它仅定义20个错误代码。对于具有如此多的外部依赖项的大量代码而言,这 并不 多。这本身就是一个问题,有成千上万种方法来弄乱图像文件。库的错误报告无法细粒度地覆盖所有错误。在.NET定义标准Exception派生类型之前很久就已经选择了这些错误代码,这一事实当然无济于事。
Status :: OutOfMemory错误代码被重载以表示不同的意思。有时确实确实意味着内存不足,它无法分配足够的空间来存储位图位。可悲的是,相同的错误代码报告了图像文件格式问题。这里的摩擦是它无法确定从图像文件读取的宽度高度像素是否是一个问题,因为没有足够的存储空间用于位图。或者,如果图像文件中的数据为垃圾数据。它假定图像文件不是垃圾文件,公平的调用,这是另一个程序的问题。所以OOM是它报告的内容。
为了完整起见,这些是错误代码:
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) };