Use FormatMessage for exception messages in cases where the stowed/language exception doesn't contain a message

[ahmed605]

Updated HRESULT to Exception conversion logic to fall back to system-formatted error messages via the Win32 FormatMessage API when custom error text is not available or is blank. This ensures more consistent and informative exception messages by leveraging Windows' built-in error descriptions.

Example:

[ahmed605]

@riverar

[manodasanW]

Thanks for the change, kicked off CI.

[ahmed605]

are the CI failures related to the PR? GitHub doesn't allow me to see the details of them

[riverar]

Can we get a test for this too? Ideally one that runs RPC_E_WRONG_THREAD through this helper to ensure it spits out the right message.

[riverar]

Think we should also clean up the commit message on merge (this is not related to WinRT Originate errors) and add a proper PR description here for our future selves looking back at this change.

Perhaps something like:

Updated HRESULT to Exception conversion logic to fall back to system-formatted error messages via the Win32 FormatMessage API when custom error text is not available or is blank. This ensures more consistent and informative exception messages by leveraging Windows' built-in error descriptions.

[manodasanW]

are the CI failures related to the PR? GitHub doesn't allow me to see the details of them

No, it is unrelated. Have a PR to fix it, after it is merged, you can rebase your changes.

[manodasanW]

Is there any test that we can add here to confirm we get expected message for a certain HRESULT.

[dongle-the-gadget]

Isn't it enough that we test the ExceptionHelpers class itself? I don't see why we need to wind up WinRT to test it.

In addition, I think we should test if the message is not empty, rather than requiring a string match, because error messages might be localized.

[riverar]

I'd still check the error message when possible to ensure we're not getting garbage. Can wrap it in a conditional so that non en-US developers don't break. If that's not a concern for this project, I'd delete the en-US check.

[Fact]
public void TestGetExceptionForHR_WithValidHResult_ReturnsSystemFormattedException()
{
    // Arrange
    const int RPC_E_WRONG_THREAD = unchecked((int)0x8001010E);

    // Act
    Exception exception = ExceptionHelpers.GetExceptionForHR(RPC_E_WRONG_THREAD);

    // Assert
    Assert.NotNull(exception);
    Assert.False(string.IsNullOrWhiteSpace(exception.Message));
    if (CultureInfo.CurrentUICulture.Name == "en-US")
    {
        Assert.Equal("The application called an interface that was marshalled for a different thread. (0x8001010E)", exception.Message);
    }
}

I can't test this for you because the build fails despite following the on-boarding instructions.

[ahmed605]

I'd still check the error message when possible to ensure we're not getting garbage. Can wrap it in a conditional so that non en-US developers don't break. If that's not a concern for this project, I'd delete the en-US check.

[Fact]
public void TestGetExceptionForHR_WithValidHResult_ReturnsSystemFormattedException()
{
    // Arrange
    const int RPC_E_WRONG_THREAD = unchecked((int)0x8001010E);

    // Act
    Exception exception = ExceptionHelpers.GetExceptionForHR(RPC_E_WRONG_THREAD);

    // Assert
    Assert.NotNull(exception);
    Assert.False(string.IsNullOrWhiteSpace(exception.Message));
    if (CultureInfo.CurrentUICulture.Name == "en-US")
    {
        Assert.Equal("The application called an interface that was marshalled for a different thread. (0x8001010E)", exception.Message);
    }
}

I can't test this for you because the build fails despite following the on-boarding instructions.

added (and tested) this, and I can confirm that building and running the UnitTest project was painful