Error Handling in Windows Programming

Get error messages in Windows Programming

In Windows programming, our functions often do not work as much as we think, and many such problems often occur. Generally, we can use their return values to determine whether they have a bad temper:

Windows Common return value type:

1) void: It indicates that the function cannot be run and the return value of WINDOWS function is rarely void.

2) bool: If the function fails to run, the return value is 0; otherwise, the return value is not 0. It is best to test the return value to determine whether it is 0 or not, rather than test whether the return value is true.

3) handle: If the function fails to run, the return value is usually null. Otherwise, the return value is a handle that identifies an object that you can operate on. Note these values. When a function fails, an invalid_handle_value is returned, which is defined as-1. The Platform SDK file of the function clearly indicates whether the returned value is null or invalid_handle_value when the function fails to run.

4) pvoid: If the function fails to run, the return value is null. Otherwise, pvoid is returned to identify the memory address of the data block.

5) Long/DWORD: This is a value that is hard to process. The function returns a long or DWORD. For some reason, the function cannot count the objects to be counted, then this function usually returns 0 or-1 (depending on the function ). If the returned value of the called function is long or DWORD, read the Platform SDK to check for potential errors.

It can be seen that getting the error information is very helpful for modifying the program. How can we get the error information. In fact, it is very simple. Windows provides three API functions for us to get error information.

DWORD winapi getlasterror (void); <br/> void winapi setlasterror (_ in DWORD dwerrcode); <br/> void winapi setlasterrorex (_ in DWORD dwerrcode, <br/> DWORD dwtype); <br/> DWORD winapi formatmessage (<br/>__ in DWORD dwflags, <br/> _ in lpcvoid lpsource, <br/> _ in DWORD dwmessageid, <br/>__ in DWORD dwageid, <br/>__ out lptstr lpbuffer, <br/>__ in DWORD nsize, <br/>__ in va_list * arguments );

DWORD winapi getlasterror (void); obtains error codes generated by system APIs. For details about codes, refer to the error codes published by msdn or Microsoft to obtain API error information,

Of course, we can also directly display the error information and how to operate it. This uses the following function.

DWORD winapi formatmessage (<br/> _ in DWORD dwflags, // specify the formatting program and the method for interpreting the lpsource parameter <br/>__ in lpcvoid lpsource, // message definition pointer <br/>__ in DWORD dwmessageid, // specify a 32-bit information identifier for the message <br/>__ in DWORD dwreceivageid, // unsupported <br/> _ out lptstr lpbuffer, // point to a buffer for formatting messages <br/>__ in DWORD nsize, // specify the size of the output buffer <br/>__ in va_list * arguments // an array of 32-bit values used to insert values in the formatted message <br/> );

 For more information, seeMsdn.

Here we use a simple example to illustrate their usage.:
Int A = getdlgitemint (idc_edit4); int B = getdlgitemint (idc_edit5); typedef int (_ stdcall * lpaddfun) (INT, INT); hinstance hdll; hdll = loadlibrary (_ T ("dll2.dll"); lpaddfun addfun = (lpaddfun) getprocaddress (hdll, "Subtract"); If (addfun! = NULL) {int c = addfun (a, B); setdlgitemint (idc_edit6, c);} else {lpvoid lpmsgbuf; lpvoid lpdisplaybuf; DWORD DW = getlasterror (); formatmessage (Response | response, null, DW, makelangid (lang_neutral, sublang_default), (lptstr) & lpmsgbuf, 0, null); response = (lpvoid) localalloc (lmem_zeroinit, (lstrlen (lpctstr) lpmsgbuf) + 40) * sizeof (tchar); stringcchprintf (lptstr) lpdisplaybuf, localsize (lpdisplaybuf), text ("failed with error % d: % s "), DW, lpmsgbuf);: MessageBox (null, (lpctstr) lpdisplaybuf, text (" error "), mb_ OK); localfree (lpmsgbuf ); localfree (lpdisplaybuf);} freelibrary (hdll );

 

The DLL is dynamically loaded. If the DLL file is successfully loaded, the subsequent code is correctly executed. If the DLL file is incorrect, a detailed description of the error message is returned. The code that follows can be used directly. If you add it to a place where an error may occur when your code calls the API, you will be prompted with the description of your function error.

Suppose we want to customize the error information in our code. This is allowed. You can use

Void winapi setlasterror (_ in DWORD dwerrcode); <br/> void winapi setlasterrorex (_ in DWORD dwerrcode, DWORD dwtype );
 

 

DWORD dwerrcode is the error code you want to set, but note that your error code cannot conflict with the system. below is the field information of the error code that has been defined by the system:

Bit	31 ~ 30	29	28	27 ~ 16	15 ~ 0
Content	Severity	Microsoft/customer	Retained	Facility Code	Exception Code
Description	0 = successful 1 = for Reference 2 = warning 3 = Error	0 = Microsoft-defined code 1 = Customer-defined code	Must be 0	The first 256 values are retained by Microsoft	Microsoft/customer-defined code

For the specific use of these two functions and the usage of these fields, please refer to the next set of stories: Exception Handling in Windows Programming and parsing of Windows structured exception handling methods.