3

I'm creating a .NET assembly that needs to be COM callable from e.g. VB6 etc.

Most of the stuff works fine - I'm fine-tuning my error handling right now.

What I'd like to do is create specific HRESULT values for my exceptions - e.g. use values like 0x88880001 etc. for my exception cases. I'd like to use a common "prefix" (like 0x8888) and then add my internal error codes (running from decimal 1001 up) to that number.

So my internal error 1001 should become HRESULT = 0x888803E9 and so forth.

I have my own custom .NET exception class, and I know I can set the protected HResult property on the base ApplicationException class - but somehow I can't manage to get my "prefix" plus my error code to work....

using System;

public class CustomException : ApplicationException
{
    public CustomException(string message, int errorCode) : base(message)
    {
        base.HResult = (uint) 0x88880000 + errorCode;
    }
}

No matter what I try here - I just cannot get a int value (for base.HResult, which is an int) that represents 0x888803E9 to be stored into my base class...

What am I missing here??

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459

2 Answers2

7

The C# compiler just hassles you to stop you from tripping an overflow bug. Justifiably, a lot of this kind of code cannot survive overflow checking, not the kind of mishap you ever want in error handling code :) Note how the code in the upvoted answer keels over with Project > Properties > Build > Advanced > "Check for arithmetic overflow/underflow" option ticked. An option that doesn't get used enough.

You have to use the unchecked keyword to suppress this runtime check:

  base.HResult = unchecked((int)(0x88880000U + errorCode));

Or you can suppress it at compile time:

  const int ErrorBase = unchecked((int)0x88880000);
  base.HResult = ErrorBase + errorCode;

Excruciatingly: the HRESULT you'll generate is not a valid one, it doesn't have a correct facility code. That code provides a hint where the error came from. Interop code should use 0x80040000 as the error base to select FACILITY_ITF. Not so sure you'll ever get any grief over 0x88880000 though, the message string you generate is most important. Unfortunately ISupportErrorInfo tends to be skipped in client code so there's no great guarantee that anybody actually sees it.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks, that seems to be doing the trick - regardless of project settings! :-) Can't believe that settings is **OFF** by default, in a C# project.... in VB - maybe, OK - but in C# - seriously? – marc_s Jul 14 '15 at 15:17
  • It is on by default in VB. Unfortunately overflow checking is pretty expensive, big loss. – Hans Passant Jul 14 '15 at 15:24
2
base.HResult = (int)((uint)0x88880000 + errorCode);

base.HResult is a System.Int32.

Your number is bigger than an Int32, however, and so it rolls over. Not sure exactly what you need and if checked might help.

However, this seems to check out:

void Main()
{
    var ce = new CustomException("uh oh", 1001);
    Console.WriteLine(ce.HResult);
    // Convert integer as a hex in a string variable
    string hexValue = ce.HResult.ToString("X");
    // Convert the hex string back to the number
    int decAgain = int.Parse(hexValue, System.Globalization.NumberStyles.HexNumber);        
    Console.WriteLine(hexValue);
    Console.WriteLine(decAgain);
}


public class CustomException : Exception
{
    public CustomException(string message, int errorCode) : base(message)
    {
        base.HResult = (int)((uint)0x88880000 + errorCode);
    }
}

Best practice is for all exceptions to derive from the Exception class.

jacoblambert
  • 787
  • 1
  • 11
  • 18