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

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

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

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

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

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

由于現在已經為不一致的返回值設置了先例，因此無論何時添加新函數，新函數是否返回NULL或INVALID_HANDLE_VALUE都有些麻煩。

這種不一致有多種后果

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

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

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

總結

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

最后

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。