WINDOWS HANDLE null INVALID_HANDLE_VALUE

输出：
1 not null
2 not null
因此CloseHandle后不能用 if ( handle ）

1. void handle_null_test()
2. {   
   
3.     HANDLE hevent = CreateEvent(NULL, FALSE, FALSE, L"xx");
   
4.     if ( hevent )
   
5.     {
   
6.         printf("1 not null\n");
   
7.     }
   
8.     CloseHandle(hevent);
   
9.     if ( hevent )
   
10.     {
    
11.         printf("2 not null\n");
    
12.     }
13. }
    

Windows API，可能会返回NULL或者INVALID_HANDLE_VALUE，具体要看MSDN。原因见下面

PS:
http://blogs.msdn.com/b/oldnewthing/archive/2004/03/02/82639.aspx
If you look at the various functions that return HANDLEs,you'll see that some of them return NULL (like CreateThread)and some of them return INVALID_HANDLE_VALUE (like CreateFile).You have to check the documentation to see what each particular functionreturns on failure.

Why are the return values so inconsistent?

The reasons, as you may suspect, are historical.

The values were chosen to be compatible with 16-bit Windows.The 16-bit functions OpenFile, _lopen and _lcreat return -1 on failure, so the 32-bit CreateFile function returns INVALID_HANDLE_VALUE in order to facilitate porting code from Win16.

(Armed with this, you can now answer the following triviaquestion: Why do I call CreateFile when I'm not actually creating a file? Shouldn't it be called OpenFile? Answer: Yes, OpenFile would havebeen a better name, but that name was already taken.)

On the other hand, there are no Win16 equivalents for CreateThread or CreateMutex, so theyreturn NULL.

Since the precedent had now been set for inconsistent return values,whenever a new function got added, it was a bit of a toss-up whetherthe new function returned NULL or INVALID_HANDLE_VALUE.

This inconsistency has multiple consequences.

First, of course, you have to be careful to check the return valuesproperly.

Second, it means that if you write a generic handle-wrapping class,you have to be mindful of two possible "not a handle" values.

Third, if you want to pre-initialize a HANDLE variable,you have to initialize it in a manner compatible with the functionyou intend to use. For example, the following code is wrong:

HANDLE h = NULL;if (UseLogFile()) {    h = CreateFile(...);}DoOtherStuff();if (h) {   Log(h);}DoOtherStuff();if (h) {    CloseHandle(h);}

This code has two bugs. First, the return value from CreateFile is checked incorrectly. The code abovechecks for NULL instead of INVALID_HANDLE_VALUE.Second, the code initializes the h variable incorrectly.Here's the corrected version:

HANDLE h = INVALID_HANDLE_VALUE;if (UseLogFile()) {    h = CreateFile(...);}DoOtherStuff();if (h != INVALID_HANDLE_VALUE) {   Log(h);}DoOtherStuff();if (h != INVALID_HANDLE_VALUE) {    CloseHandle(h);}

Fourth, you have to be particularly careful with the INVALID_HANDLE_VALUE value:By coincidence, the value INVALID_HANDLE_VALUE happens to be numerically equal to the pseudohandle returned by GetCurrentProcess().Many kernel functions accept pseudohandles, so ifif you mess upand accidentally call, say, WaitForSingleObject on afailed INVALID_HANDLE_VALUE handle, you will actuallyend up waiting on your own process. This wait will, of course,never complete, because a process is signalled when it exits,so you ended up waiting for yourself.