問題描述
我正在編寫代碼來捕獲這個 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)
};
這篇關于Image.FromFile 是否為無效的圖像格式拋出 OutOfMemoryException 的原因?的文章就介紹到這了,希望我們推薦的答案對大家有所幫助,也希望大家多多支持html5模板網!