Ian Pilcher pilcher@concentric.net writes:
In theory, yes. But what about the case of a mistake on my part (or the part of the person who implemented the underlying call)? We all do everything possible to produce error-free code, but mistakes *do* happen.
IMHO the likelihood that your macros are going to introduce new bugs is larger than the likelihood that you are ever going to catch a legitimate failure from HeapFree(). Not to mention that there are already WARNs in the heap code that will catch the problem first, so your messages are redundant.
Checking for errors is good if you actually handle failures; but if you don't do anything it just obscures the code for no good reason.
Alexandre Julliard wrote:
IMHO the likelihood that your macros are going to introduce new bugs is larger than the likelihood that you are ever going to catch a legitimate failure from HeapFree(). Not to mention that there are already WARNs in the heap code that will catch the problem first, so your messages are redundant.
I can't argue with that, since it has been pointed out that the macros can cause problems with if, then, else constructs. (Is there an "emoticon" for embarrassment?) It is possible, however, to fix this.
And please don't overemphasize my HeapFree() example; that was completely hypothetical. I have no knowledge of when HeapFree (or RegCloseKey) might fail with valid inputs, nor do I want to know.
Checking for errors is good if you actually handle failures; but if you don't do anything it just obscures the code for no good reason.
In a development/test environment, I think that issuing a warning message is constructive. HeapFree, RegCloseKey, etc. may issue warnings if they fail for legitimate reasons; then again they may not. I haven't looked at the source code for these functions, and I don't think that I should have to. (Going back to the hypothetical, I could also argue that we may want to test Wine DLLs within Windows someday.)
The obscure code issue takes us back to the macros, so the circle is complete . . .