Why is there multiple Err.Number for the same Err.Description?

Question

Hi,

Reading various properties of the Outlook.MAPIFolder.Items collection results in an error when the user permissions are insufficient, for example if the folder is visible but no browsable.

The error description is: You do not have sufficient permission to perform this operation on this object. See the folder contact or your system administrator.

I wanted to trap that error this way (in Outlook 2003):

Sub MySub(StartFolder As Outlook.MAPIFolder)

...

On Error GoTo ErrHandler
If (StartFolder.Items.Count = 0) Then Exit Sub 'this really is a permission test'
On Error GoTo 0

...

ErrHandler:
  If ((Err.Number <> 0) And (Err.Number <> -2114519035)) Then
Call MsgBox("Error " & Err.Number & ": " & Err.Description, vbExclamation + vbOKOnly, StartFolder.Name, _
            Err.HelpFile, Err.HelpContext)
...
End Sub

Testing my error handler, I found another error number having the same description... and the list grew quickly to 62 errors having the same description! Err.Number ranges from -2114519035 to -1638395. All error numbers look like FFxxx70005 in hex.

Why is there multiple Err.Number for the same Err.Description? How would you trap these errors, and only them, easily? Is the hex error number structure characteristic of this error?

Oh, and I don't like the idea of testing the description (too locale- and version-specific).

Answer 1

That error number looks like an HRESULT - see the page for HRESULT on Wikipedia.

The piece that's varying for you, that you have marked as xxx, is the "Facility", or in other words, which part of Windows is returning the error.

The actual error is in the bottom 16 bits, or 0x00005 in your case, which means "Access denied". The values you're seeing are all the different ways that Windows can say "Access denied", eg. "Access denied to a file", "Access denied to the certificate store", "Access denied to a network service", etc.

Take the bottom 16 bits of the error and compare with 5 to trap all the cases where "the user permissions are insufficient".

Answer 2

I believe this is because the requested operation is compound, that is, requires multiple calls to various COM interfaces, each of which can return a different HRESULT describing an error that occured at that little step. The enclosing method tries to generate a more user-friendly message, so in case of any error it gives out the same error string (which is usually a good thing to do, usability-wise). At the same time, the original COM error code is preserved in case someone would care.

I think in this case the best you can do is doing the same, i.e., giving out the same user-friendly string for all error codes.

If you actually want to analyse the error codes, you want Structure of COM Error Codes.