如果查看返回HANDLE的各種函數(shù), 你就會發(fā)現(xiàn)其中一些返回NULL(例如CreateThread)，而另一些會返回INVALID_HANDLE_VALUE(例如CreateFile)。所以，你必須查看相關(guān)的MSDN文檔，才能確定函數(shù)在執(zhí)行失敗時的返回值的意義。

為什么句柄返回值如此不一致？

可能你早就猜到了：因為歷史原因。

這些句柄的值被這樣選擇，主要是為了和16位Windows保持兼容。
16位函數(shù)OpenFile，_lopen和_lcreat在失敗時返回-1，因此32位CreateFile函數(shù)返回INVALID_HANDLE_VALUE以便于從Win16移植代碼。

(知道了這個，我們就應(yīng)該可以回答這個問題您現(xiàn)在可以回答以下瑣事問題：為什么我想打開一個文件時需要調(diào)用CreateFile? 不是應(yīng)該調(diào)用OpenFile嗎？答：當然可以，OpenFile是一個更好的名稱，但是該名稱已被使用。)

另一方面，對于CreateThread或CreateMutex，沒有Win16對應(yīng)的版本，因此它們返回NULL。

由于現(xiàn)在已經(jīng)為不一致的返回值設(shè)置了先例，因此無論何時添加新函數(shù)，新函數(shù)是否返回NULL或INVALID_HANDLE_VALUE都有些麻煩。

這種不一致有多種后果

首先，當然，你必須小心檢查正確的返回值。
其次，這意味著，如果編寫通用的句柄包裝類，則必須注意兩個可能的”非句柄”值。
第三，如果要預(yù)初始化句柄變量，則必須以與要使用的功能兼容的方式對其進行初始化。例如，以下代碼是錯誤的：

以上代碼有兩個錯誤。
首先，從CreateFile返回的值檢查不正確。 上面的代碼檢查NULL而不是INVALID_HANDLE_VALUE。 其次，代碼錯誤地初始化了h變量。下面是更正后的版本：

第四，你必須特別小心INVALID_HANDLE_VALUE值：巧合的是，值INVALID_HANDLE_VALUE恰好在數(shù)值上等于GetCurrentProcess()返回的偽句柄。許多內(nèi)核函數(shù)都接受偽句柄，因此，如果你搞砸了并且不小心在一個失敗的INVALID_HANDLE_VALUE句柄上調(diào)用了WaitForSingleObject，實際上你將最終等待自己的進程。
當然，這種等待永遠不會完成，因為當退出某個進程時會發(fā)出信號，因此你最終要等待你自己。

總結(jié)

如有必要，請檢查每一個Win32 API的返回值。

最后

Raymond Chen的《The Old New Thing》是我非常喜歡的博客之一，里面有很多關(guān)于Windows的小知識，對于廣大Windows平臺開發(fā)者來說，確實十分有幫助。
本文來自：《Why are HANDLE return values so inconsistent?》

總結(jié)

以上是生活随笔為你收集整理的函数失败返回_为什么句柄返回值不一致？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。