Very sleepy today, this is why?!! Just read the first chapter, sleepy to No, so write blog sober.
The first chapter of the title is "error handling", after looking at the startled, is it the first chapter on such a tall thing?! No, no, I now understand that this chapter is mainly to show us how to get a description of the problem and how to know it.
After we use the function, there is always a result: failure or success. The result, ultimately, is to fall on the ground in the form of an identity, in which the main story is the return Long/dword type. Each function will eventually return an error code to the calling thread.
Want to see what is returned, here is a method:DWORD GetLastError();
In Windows, there is a file (WinError.h) has a list of error codes, this file is very large, just take one element out of reference.
messageid:error_success////messagetext:////The operation completed successfully.//#define ERROR_SUCCESS 0L
Each error consists of three elements:
An error ID, which is identified by the above MessageID, is also a macro;
One is a description of the error, which is what MessageText identifies;
One is the number.
It is recommended to use an ID instead of a number.
And then there's a little bit of it. Understand: Some Windows function call success may be due to different reasons. For example, when creating a named event kernel object, the following two scenarios are successful: the object is actually created, or there is an event kernel object with the same name. The application may need to know the cause of the success. To return this information, Microsoft opted to use the last error code mechanism. Therefore, when a particular function call succeeds, you can call GetLastError to determine additional information. For functions with this behavior, the Platform SDK documentation clearly indicates that GetLastError can be called in this manner. An example of the CreateEvent function is provided in the documentation, and if a named event already exists, the error_already_exists is returned. (I'll look back later)
We can see the previous error code and the text description through the Debug window, and I tried it and I did.
And the VS comes with gadgets, error look up:
Here's a look at the key functions for getting text descriptions:
| 12345678 |
DWORDFormatMessage( DWORD dwFlags, LPCVOID pSource, DWORD dwMessageId, DWORD dwLanguageId, PTSTR pszBuffer, DWORD nSize, va_list*Arguments); |
FormatMessage can support a variety of languages, such as English, Chinese, and so on, we see in the above example, the return is Chinese.
In addition to the code in WinError.h, we can customize the error code back:VOID setlasterror(DWORD dwerrcode);
The book also gives us an example:
The idea is to get the user input error code, then get the system language (Chinese, English), and then use FormatMessage to return the query results.
| 1234567891011121314151617181920212223242526272829303132333435363738394041 |
caseIDOK: // Get the error code DWORDdwError = GetDlgItemInt(hwnd, IDC_ERRORCODE, NULL, FALSE); HLOCALhlocal = NULL; // Buffer that gets the error message string // Use the default system locale since we look for Windows messages. // Note: this MAKELANGID combination has 0 as value DWORDsystemLocale = MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL); // Get the error code‘s textual description BOOLfOk = FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS | FORMAT_MESSAGE_ALLOCATE_BUFFER, NULL, dwError, systemLocale, (PTSTR) &hlocal, 0, NULL); if(!fOk) { // Is it a network-related error? HMODULEhDll = LoadLibraryEx(TEXT("netmsg.dll"), NULL, DONT_RESOLVE_DLL_REFERENCES); if(hDll != NULL) { fOk = FormatMessage( FORMAT_MESSAGE_FROM_HMODULE | FORMAT_MESSAGE_IGNORE_INSERTS | FORMAT_MESSAGE_ALLOCATE_BUFFER, hDll, dwError, systemLocale, (PTSTR) &hlocal, 0, NULL); FreeLibrary(hDll); } } if(fOk && (hlocal != NULL)) { SetDlgItemText(hwnd, IDC_ERRORTEXT, (PCTSTR) LocalLock(hlocal)); LocalFree(hlocal); } else{ SetDlgItemText(hwnd, IDC_ERRORTEXT, TEXT("No text found for this error number.")); } break; |
The error code is recorded in the dwerror variable;
Hlocal is the record description string;
SystemLocale is to indicate what language to display the text description, based on two specific constants (that is, lang_neutral and sublang_neutral) to generate the language identifier, the two constants together will generate a 0 value-the default language of the operating system;
Let's take a look at the parameters passed in FormatMessage:
Format_message_from_system: We want to get a string corresponding to a system-defined error code,
Format_message_allocate_buffer: This function is required to allocate a piece of memory sufficient to accommodate the error text description. The handle to this block of memory is returned in the hlocal variable,
Format_message_ignore_inserts: Allows us to obtain a message containing a% placeholder. These placeholders will be used by Windows to provide more context-sensitive information;
The third parameter indicates the error code you want to find;
The fourth parameter indicates what language to use to display the text description;
Fok records whether the query is successful, if the query fails, then determine whether the error is related to the network (this is not understood here), otherwise you can output.
Summarize
This chapter gives you an idea of how to customize the error code, and how to get an error description from the error code. Please select the content you want to save and paste it into this text box
Windows core Programming Reading notes 1