One of the most frustrating part of debugging is when at a certain point the return value of a call is just a generic error code (eg. E_FAIL) or false without proper last error set. The failure might have happened deep in the call stack and now you have to step into each call to figure out exactly where it failed. This arises most of the times due to the fact your API return type and the return type of something you call doesnt match forcing you to use generic failure code. But most of the times, you can map error codes of one type to another (example). For example, consider a simple example
1 HRESULT SomeAPI()
2 {
3 HANDLE hThread = NULL;
4 HRESULT hr = S_OK;
5 hThread = CreateThread(…);
6 if (NULL != hThread)
7 {
8 if (SomeAPI2()) // SomeAPI2 sets the last error code
9 {
10 hr = SomeAPI3();
11 }
12 else
13 {
14 hr = E_FAIL;
15 }
16 }
17 else
18 {
19 hr = E_FAIL;
20 }
21 return hr;
22 }
Now, after calling SomeAPI, if the return value is E_FAIL, I am at loss as to where the failure was. But instead if the programmer was a bit more diligent and changed lines 14, 19 to more meaningful return values using HRESULT_FROM_WIN32(GetLastError()), I would have a better idea as to what failed (an error in creating the thread or failure in SomeAPI2. This I believe greatly helps in debugging issues faster. This also causes the side effect of losing the error value up in the call stack, for example if this code segment did some file-system specific operations (assuming no other calls in the stack did this), if I get to know the error was something related to files (ERROR_FILE_NOT_FOUND), I would instantly know which call/code segment to investigate deeper.