Anonymous Exception Catching

I was going through the FlexWiki code the other day, and I saw this block of code:

catch (FormatException ex)
{
    ex.ToString(); // shut up compiler;
}

I've seen this before: you know an exception is going to be thrown, and you also know that it's safe to ignore it. (You should think twice about doing this, but sometimes it's unavoidable.) And that annoying little call to ToString() winds up in there because otherwise the compiler pitches a warning about there being an unreferenced local variable. Although it's only a warning, and could in theory just be ignored, many build systems wisely compile their code with the warning level set to maxiumum, which would actually turn this into a compilation error.

The code often gets written this way because developers don't realize that you can safely do this:

catch (FormatException)
{
}

Notice that there's no exception variable. This will compile just fine, and it does exactly the same thing the previous code does - silently throws the exception away. Only now we don't have that confusing extra line of code in there, and the compiler won't complain about unused variables.

I should point out that there actually is one case where you might want to leave that line of code in. If you want to be able to view the exception while debugging, it's convenient to have a variable to examine in the debugger. However, in that case, I would recommend using this code instead:

catch (FormatException ex)
{
    Debug.WriteLine(ex.ToString());
}

This has the advantage that under a Debug build, you can still set a breakpoint and examine the exception. However, because System.Diagnostics.Debug.WriteLine is marked with the [Conditional(”Debug”)] attribute, it will not be compiled at all under a Release build - it'll be like that line of code isn't even there.

This is a slick little bit of compiler magic that you can take advantage of in your own code to write functions that disappear from your Release builds. Check out the documentation on the Conditional attribute for more information.

Yukon Issues Solved

With a little help from my friends (thanks Tim and Brian), I got my Yukon problems sorted out. The fundamental issue was that I had forgotten to install the Yukon test certificate before installing Yukon itself. Apparently, one of the pieces is signed with this, and the signature check fails during installation if the certificate hasn't been installed. So after re-running the install, everything appears to be working well.

The biggest mystery, though, is that all my .NET 1.1 stuff started working before I got Yukon running again. And I'm not sure what I did, although I suspect removing .NET 1.1 paths from the LIB environment variable might have been the key. Unfortunately, I wasn't very scientific in my desperate flailing. I'm just happy it works.

Win32 to .NET API Mapping

The inestimable Tim Tabor posted this on the WinTech Off-Topic Mailing List today:

His summary: “Wow”. I concur.

Direct3D "Creating a Mesh" Tutorial Available

What have I been working on lately? Well, I plan to explain in a bit more detail later, but this last week I wrote another Direct3D tutorial. It's about how to manually create a Direct3D Mesh, and you can find it here. As a bonus, I also briefly discuss z-bias and wireframe rendering.

Looking back, I've been writing these for just over a year - I published my first one on January 20th, 2003. Since there are now 15 in the series, that means I've been doing better than one a month. On top of that, I also did a short DirectSound tutorial series. Which, when I thought about it, surprised me: I felt like I've been slacking on these lately, but that rate is better than what you get from a regular magazine column.

But enough tooting my own horn - enjoy!

Another Band on the Runtime

I was listening to Progged Radio today. It's my favorite “radio” station - it's hard to find the obscure branch of music I like (progressive metal).

Anyway, a song came on, and I had to laugh. It was the title track from “Marathon” by SAGA, and the chorus goes something like this:

It takes time to get to avalon
That's why we're on this marathon

Full lyrics here.

I think someone from the Avalon team needs to pick up this album for those long nights of coding.

Yukon D'oh!

While I was out in Seattle last week, I stopped off at MSDN to talk to some people about getting going on the project I'll be working on. One of the exciting pieces is that we're going to be using some really bleeding-edge stuff, like Yukon and Whidbey. So it was convenient for me to grab the interim builds of these products, since that's we're going to develop against. In fact, we expect to track the product teams pretty closely, updating our development environment frequently with new builds.

Like I said, this is exciting for nerds like us. But like most things, it's a tradeoff; we knew that it was going to cause us some pain. This weekend I encountered the first pangs. In the middle of installing Yukon, I got an error message to the effect of “MDAC does not meet the Windows Logo requirements. It will not be installed.” Then the whole install rolled back.

In and of itself, that doesn't sound too bad, but in the wake of it, neither the .NET 1.1 C# compiler nor any version of ASP.NET works on that machine. Joy. Hopefully we'll get it sorted out soon. In the meantime, I guess I can do command-line compiles of my side projects (more about those later) with the Whidbey C# compiler. Not the greatest setup, but enough to give me some confidence before I do a check-in.

Back in the MSDN Saddle Again

I'm in Seattle this week, visiting my wife's relatives. As long as I was here, I paid a visit to the Microsoft Campus, specifically to building 5. I needed to sign some paperwork so I can get started working on the MSDN re-architecture again. I've been off the project for about six months, but now it's really spinning up again - the work we did before was only the beginning.

What does this mean for you, dear reader? Well, since we're going to be doing a lot of cool stuff at MSDN, and since I have clearance to blog, you can expect to hear about it here. For example, MSDN is making the extremely bold move of implementing using pre-release versions Whidbey and Yukon. I've always admired this sort of “eat your own dogfood” philosophy, and now I actually get to be paid to play with the stuff. Woohoo!