Clearing the last error using SetLastError
Mike Goelzer
I was wondering what the standard procedure for clearing the
value returned by GetLastError is. Because of the way my
program has to check the value of GetLastError, it gets screwed
up unless I use SetLastError(0) to set the last error to zero.
But is setting it to 0 the right thing to do? Or is there
some #define'd number that I should set the error code to? Is
an error of 0 considered an error, or is this the proper protocol
for clearing the previous error.
Dave Corboy
What you are doing is just fine and is, in fact, recommended for isolating
the source of errors from GetLastError. You should probably use
SetLastError(NO_ERROR) or
SetLastError(ERROR_SUCCESS) both of which are defined as (0L).
Hope that helps,
--
Dave Corboy |
dco...@adobe.com | GCS d(--) H++ s+:+ g- au+ a-
"A 64-bit Programmer Writing 32-bit | v(*) C++ N++ W++++$ M+ po---
Code On A 2-bit Operating System" | Y+ t++ 5-- !D B-- e++ r++ x+
Bill McCormick
First be sure that you really need to do this. In general you should
be checking GetLastError() iff an error was reported from a call or
to check the status of a call which reports errors via GetLastError().
If you really do need to set it, use NO_ERROR or ERROR_SUCCESS. Both
are defined as "0".
Bill
hamilton on BIX
Generally speaking, the convention is that you only check GetLastError
when you know it contains useful information. For example, if
you make a call that's supposed to return a handle and the handle
comes back as invalid (determined by comparing against
INVALID_HANDLE_VALUE), you can call GetLastError to diagnose
why that happened. But you should not try diagnosing whether
the call succeeded/failed by calling GetLastError since the
convention is that GetLastError is set only if an error has
occurred; otherwise it contains just whatever garbage has been
laying around in there.
If you follow that convention, then obviously there's never a
need to set the LastError value. And if you're saying, well, in
my program, I need to, then my suggestion would be to examine your
design carefully to see if you can avoid that. In general, I think
you may find this is one of those cases where it's probably easy
both to underestimate the cost of violating the convention and
to overestimate how much work it might take to follow it.
Regards,
Doug Hamilton KD1UJ hami...@bix.com Ph 508-440-8307 FAX 508-440-8308
Hamilton Laboratories, 21 Shadow Oak Drive, Sudbury, MA 01776-3165, USA
Dave Corboy
BIX) wrote:
I have to take exception to this reply and point out that sometimes it may
be neccesary to use SetLastError. From the docs, "Win32 API functions that
return indications of failure call SetLastError when they fail. ...they do
NOT call SetLastError when they succeed." Thus, without first setting the
last error to NO_ERROR, how is one to know if the current value returned
by GetLastError is the result of the most recent API call? Before you say
"check the return value of every API function," be aware that some
functions (notably LoadLibrary) can return success yet still set an error
condition. In LoadLibrary, the success indicator may be returned (non-NULL
hInstance) yet the specification of a 16-bit library filename will cause
GetLastError to return ERROR_BAD_FORMAT indicating that a subsequent
FindResource will fail.
hamilton on BIX
>In article <hamilton....@BIX.com>, hami...@BIX.com (hamilton on
>BIX) wrote:
>> ... In general, I think
>> you may find this is one of those cases where it's probably easy
>> both to underestimate the cost of violating the convention and
>> to overestimate how much work it might take to follow it.
>I have to take exception to this reply and point out that sometimes it may
>be neccesary to use SetLastError. From the docs, "Win32 API functions that
>return indications of failure call SetLastError when they fail. ...they do
>NOT call SetLastError when they succeed." Thus, without first setting the
>last error to NO_ERROR, how is one to know if the current value returned
>by GetLastError is the result of the most recent API call? Before you say
>"check the return value of every API function," be aware that some
>functions (notably LoadLibrary) can return success yet still set an error
>condition. In LoadLibrary, the success indicator may be returned (non-NULL
>hInstance) yet the specification of a 16-bit library filename will cause
>GetLastError to return ERROR_BAD_FORMAT indicating that a subsequent
>FindResource will fail.
First, let me apologize if it seemed I was taking an overly dogmatic
approach to the problem. In my mind, I meant for the phrase "In general"
to have real meaning, which is to say, I never imagined that it should
apply to every imaginable case. As I went on to say in private email
to the person who'd asked the original question, if he's examined
his problem, found it to be uniquely suited for a use of SetLastError,
I certainly have no quarrel. That's just good engineering to recognize
that special cases do arise.
That said, the way you are _supposed_ to determine if a call has
succeeded or failed is by examining the results returned by that call,
not by calling GetLastError. If, as you say, LoadLibrary has the
characteristic of sometimes returning a non-NULL handle even when, in
fact, it has failed, this is clearly contrary to the documentation
and, in my judgement, almost certainly a bug. (Have you reported
this anomoly to MS? What's been their response?)
Obviously, we do sometimes, as good engineers, have to work around
known bugs in components over which we have no control. This is
without question an exception situation and, I hope we can all agree,
not the situation on which we should base general rules.
Robin Chalaire
(Dave Corboy) writes:
Goelzer is right 100 per cent!
Rob