Reading a contract from the other side: Application publishers

re: Reading a contract from the other side: Application publishers

Raymond Chen — Thu, 02 Sep 2004 16:34:00 GMT

And that's what the NT team did - with STATUS and HRESULT codes. But the registry stuff predates NT. The only thing the NT team could do with the registry stuff was come up with names for things that already existed.

re: Reading a contract from the other side: Application publishers

Norman Diamond — Thu, 02 Sep 2004 02:15:00 GMT

8/31/2004 6:46 PM Raymond Chen

> It's called ERROR_SUCCESS because it's an
> error code [...] What would you call it?

I would have defined return codes or status codes instead of error codes. I would have allowed the possibility of a successful return code or successful status code. I would probably call the thing SUCCESS or STATUS_SUCCESS. Despite my cynicism, I think there were known cases of operations performing as intended even before the codes here were designed as error codes.

For comparison: When programs under VMS returned a value whose meaning meant a warning level but success, the fault was in those programs not the OS. The OS did define a value whose meaning meant a success level together with success. The OS came with impeccable documentation of this fact. Some programs even obeyed it.

re: Reading a contract from the other side: Application publishers

darwou — Wed, 01 Sep 2004 05:44:00 GMT

> Now just to be snarky, having observed
> cases of "if ([...] == ERROR_SUCCESS)"
> and "if (SUCCEEDED([...]))" in the same
> code sample, I can't help wondering.
> Shouldn't the latter macro have been
> ERROR_SUCCEEDED? Or ERRORED_SUCCESSFULLY?

SUCCEEDED() is unrelated to ERROR_SUCCESS.

HRESULTS are not Win32 errors.

ERROR_SUCCESS is the Win32 error code indicating success. It is defined as 0.

Win32 API errors are positive integers. For example, ERROR_NOT_ENOUGH_MEMORY is defined as 8.

On the other hand, an HRESULT is an error returned from a COM interface or API.

S_OK is the error code that indicates success. It is also defined as 0.

However, HRESULT codes representing errors are all negative. For example, E_OUTOFMEMORY is defined as 0x8007000E.

SUCCEEDED() and FAILED() are both macros designed to work only with HRESULT. They check to see if the error code is negative to determine whether to return TRUE or FALSE.

Hence, you must NEVER use either macro with the error code returned from a Win32 API like RegEnumKeyW or RegQueryValueW().

re: Reading a contract from the other side: Application publishers

Raymond Chen — Wed, 01 Sep 2004 01:46:00 GMT

It's called ERROR_SUCCESS because it's an error code (and therefore must be named ERROR_something) but no error occurred. What would you call it?

re: Reading a contract from the other side: Application publishers

Norman Diamond — Wed, 01 Sep 2004 01:18:00 GMT

Seriously, a lower-case l is a terrible name for an identifier, whether or not you intend for your code to be read by humans.

Now just to be snarky, having observed cases of "if ([...] == ERROR_SUCCESS)" and "if (SUCCEEDED([...]))" in the same code sample, I can't help wondering. Shouldn't the latter macro have been ERROR_SUCCEEDED? Or ERRORED_SUCCESSFULLY?
Too bad this one doesn't have a screenshot:
http://www.sonic.net/~ezzell/Error%20Messages/Nothing_Goes_Wrong_Like_Success.htm#Nothing_Like_Success
but this one does:
http://home.comcast.net/~anon4321/niceone.gif

re: Reading a contract from the other side: Application publishers

Filip — Tue, 31 Aug 2004 17:38:00 GMT

You may call me pedantic ... but I tried to compile your program:

if (SUCCEEDED(CoInitialize(NULL))) { <-- Missing parenthesis

and

if (RegQueryValueW(hkPub, szKey, szCLSID, &l) == ERROR_SUCCESS)
{ <== Missing bracket

re: Reading a contract from the other side: Application publishers

Michael — Tue, 31 Aug 2004 15:57:00 GMT

What a great article! I am going to sit down and run some tests and really sink my teeth into this subject for some work I have to do later next week. What a great resource your site has become. Thanks! Finally, for one am glad you do not use smart pointers in you examples. Not that I do not use raw pointers in my work, it just makes it easier to follow.