Code in filtered exception handler throws NullReferenceException when accessing exception

Question

When I compile a UWP app with the .NET Native compiler and turn on code optimizations (essentially release mode), then I get a NullReferenceException when I try to access the actual exception in the catch block.

Code Sample:

try
{
    throw new ArgumentNullException("Param");
}
catch (ArgumentNullException ex) when (ex.ParamName == "Param")
{
    ErrorBlock.Text = ex.ParamName; // ErrorBlock is a TextBlock in the xaml
}
catch (Exception)
{
}

It goes into the correct catch block, and throws a NullReferenceException when I access ex. This only fails if both .Net Native and code optimizations are on.

What causes this issue?

Accommodation

@Pan why remove the tags? It seems related to this build mode and thus possibly a compiler problem with .NET native. – Maceio

Because they are irrelevant. exc.Message is null. This is a plain NulLReferenceException. The OP called the constructor that only accepts a parameter name – Smitty

No, it is not... The message is defaulted. Please try this code yourself. – Maceio

Yeah this is not a plain NRE... The exception can be de-referenced fine on the line above it. – Accommodation

"The exception can be dereferenced fine on the line above it" - well yes and no, exception filters aren't that straightforward. – Ogdoad

Answer 1

I work on the .NET Native runtime and compiler team.

This is a bug inside of our compiler. You can think of each exception handling region (try, catch, finally, when) as a small function or "funclet". We lose track of the exception object when setting up the stack for the "when" (aka filter block). This bug is corrected in Windows Tools 1.3 which, given no major setbacks, should be shipping in another week or two. It'll show up as an update for folks that have installed VS 2015 Update 2.

Let me know if you have any other questions.

Gerrygerrymander

Thanks @Matt! I saw slightly different behaviors in 3 scenarios around this: non-async, async but not awaited, and async + awaited. I'll give all 3 a shot when the update comes out. – Accommodation

Excellent. Please let us know how it goes. We love hearing from folks at [email protected]. – Gerrygerrymander

Answer 2

I am not exactly sure why it is going wrong (have been debugging for quite some time now), but the lack of await made me curious.

If you do await the ShowAsync method the code runs without a problem (obviously you need to make the method async if you didn't do that yet):

await new MessageDialog("Argument null exception: " + argEx.Message).ShowAsync();

While the code block without the await failed. Not sure if this is a bug or something you should have fixed...

Maceio

Hmm, that worked for me as well! I didn't realize it was related to async/await. The actual code I found this in is not awaiting a particular result by design (it's all in ICommands anyway so they'd be async void). I don't think you should be required to await this anyway, right? – Accommodation

Yes, every async should be awaited. – Maceio

This is a long running task and I don't need to schedule a continuation afterwards. I want the fire-and-forget behavior here. Awaiting it isn't really an option. – Accommodation

I did some more tests, this doesn't look related to async/await after all. – Accommodation

Can you tell us what you've found? – Maceio

I've updated the code. Instead of using MessageDialog, I added a textblock to the page and tried just updating that. I still get a NRE but weirdly I can access the exception in the debugger. – Accommodation