C# – Catching COMException specific Error Code

ccom

I'm hoping someone can help me. I've got a specific Exception from COM that I need to catch and then attempt to do something else, all others should be ignored. My error message with the Exception is:

System.Runtime.InteropServices.COMException
(0x800A03EC): Microsoft Office Excel
cannot access the file 'C:\test.xls'.
There are several possible reasons:

So my initial attempt was

try
{
 // something
}
catch (COMException ce)
{
   if (ce.ErrorCode == 0x800A03EC)
   {
      // try something else 
   }
}

However then I read a compiler warning:

Warning 22 Comparison to integral
constant is useless; the constant is
outside the range of type
'int' …..ExcelReader.cs 629 21

Now I know the 0x800A03EC is the
HResult and I've just looked on MSDN
and read:

HRESULT is a 32-bit value,
divided into three different fields: a
severity code, a facility code, and an
error code. The severity code
indicates whether the return value
represents information, warning, or
error. The facility code identifies
the area of the system responsible for
the error.

So my ultimate question, is how do I ensure that I trap that specific exception? Or how do I get the error code from the HResult?

Thanks in advance.

Best Answer

The ErrorCode should be an unsigned integer; you can perform the comparison as follows:

try {
    // something
} catch (COMException ce) {
    if ((uint)ce.ErrorCode == 0x800A03EC) {
        // try something else 
    }
}

Related Solutions

C# – Why catch and rethrow an exception in C#

First; the way that the code in the article does it is evil. throw ex will reset the call stack in the exception to the point where this throw statement is; losing the information about where the exception actually was created.

Second, if you just catch and re-throw like that, I see no added value, the code example above would be just as good (or, given the throw ex bit, even better) without the try-catch.

However, there are cases where you might want to catch and rethrow an exception. Logging could be one of them:

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

C# – Try-catch speeding up the code

One of the Roslyn engineers who specializes in understanding optimization of stack usage took a look at this and reports to me that there seems to be a problem in the interaction between the way the C# compiler generates local variable stores and the way the JIT compiler does register scheduling in the corresponding x86 code. The result is suboptimal code generation on the loads and stores of the locals.

For some reason unclear to all of us, the problematic code generation path is avoided when the JITter knows that the block is in a try-protected region.

This is pretty weird. We'll follow up with the JITter team and see whether we can get a bug entered so that they can fix this.

Also, we are working on improvements for Roslyn to the C# and VB compilers' algorithms for determining when locals can be made "ephemeral" -- that is, just pushed and popped on the stack, rather than allocated a specific location on the stack for the duration of the activation. We believe that the JITter will be able to do a better job of register allocation and whatnot if we give it better hints about when locals can be made "dead" earlier.

Thanks for bringing this to our attention, and apologies for the odd behaviour.

Related Topic

C# System.Runtime.InteropServices.COMException (0x800A03EC): Exception from HRESULT: 0x800A03EC Microsoft.Office.Interop.Excel._Workbook.SaveAs()