Random header image... Refresh for more!

WPF WTF

I’ve recently been working on a small project using WPF.  It’s the first time I’ve done anything of significant worth in WPF.  I’ve done some things in Silverlight before, but nothing in full WPF.

I wrote some code, ran it, and it didn’t perform as expected.  I got a blank window instead of the colorful boxes I was expecting.  No errors, just a blank window.  I set a breakpoint and stepped through the code.

Step…

Step…

Step…

Nothing.

Right in the middle of a function, the control had jumped somewhere else.  No unintentional return, no exception, no freak goto statement.  The debugger had gone from the line it was supposed to be on to telling me that it was no longer in the function where it should have been.

I looked at the line.

CurrentSlide.Initialize();

Well, that’s where the problem is.  The property CurrentSlide is not assigned at that point.  Originally it had been, but I changed the code around so that it’s set only after I make sure that the new slide is valid and worthy of becoming the CurrentSlide.  The line should be:

newSlide.Initialize();

But hold on a minute.  That original line should throw a NullReferenceException.  I got nothing.  Obviously something was going wrong because execution was leaving the function.  That’s consistent with throwing an exception at that line, but what happened to it?  I’m in Visual Studio and debugging the application.  I should get a big window screaming about a NullReferenceException and telling me precisely what line it’s on.  There aren’t any try/catch blocks in my code yet because nothing I’m doing is expecting any exceptions, and there wouldn’t be anything I could do about them at this point, anyway.  So…  WTF?

Then I see this in the output window of VS:

A first chance exception of type 'System.NullReferenceException' occurred in BuildMonitor.dll

Well, THERE’S my exception, hanging out in the output window.  Where I’m obviously going to find it.  No stack trace.  No exception message.  Just the type and the assembly the exception was thrown from.  Ever so helpful.

It appears that WPF is swallowing exceptions in my code.  WTF?  I mean, I’d really like to know about unhandled exceptions in my application, especially when I’m debugging.  You know, since unhandled exceptions are generally indicative of problems that, you know, need to be fixed.

So, maybe there’s an unhandled exception event that I can attach to.  I know that AppDomain has one that I’ve used before, so I try it, but that doesn’t help.  The exception is being captured somewhere above that level.  So, I Dogpile around for others that have had the same problem.  I see a lot of people who are complaining that WPF isn’t throwing binding exceptions to them.  Not quite my problem, but close enough.  The recommendation is to hook up your own handler to the Dispatcher.UnhandledException event and write out the error yourself.  Not perfect, but at least I’ll get a stack trace that way.  So, I hook it up and try it out.

AND THIS TIME I GET THE VS EXCEPTION DIALOG!

WTF?  I handle an unhandled exception that was silently being handled by something, and that stops whatever was handling it from handling it and therefore makes it unhandled so that Visual Studio picks it up?  I repeat, WTF WPF?

So, here’s the code that I’ve added to my app’s constructor to make things happy:

Dispatcher.UnhandledException += (x, y) => { };

I attach to the Dispatcher.UnhandledException event and do absolutely nothing, and now I’ll get exceptions from my WPF app showing up in Visual Studio.

0 comments

There are no comments yet...

Kick things off by filling out the form below.

Leave a Comment