I gave another talk at the Utah Spring Code Camp this past Saturday. I originally proposed giving a 3-part XNA Game Studio Express talk, but my mail wasn’t being received by the organizer. Why? Well, because I’ve been on the internet for so long that spammers actually use my email address as the forged From address on the spam they send out. Occasionally I get the bounced back virus or spam message that shows clearly that they are forging my address as the originating address. However, lately people have reported not getting email that I send to them and I can only assume its because the forged spam has resulted in my mailing address being placed on blacklists as a “source of spam”. Obviously the maintainers of these blacklists aren’t analyzing the mail very carefully, but its just one more reason why you never want to meet me and admit to being a spammer. I’m likely to just give you a swift knee to the groin without a second thought.
Anyway, so my original proposal of a 3-part XNA talk wasn’t received in time, so I ended up talking about a technique for mapping error status codes to C++ exceptions. This is the same technique that I discuss in the first chapter of my book on Direct3D. I won’t go into the details of the error handling technique here, you can read that in the chapter and download the sample code for the book to see an implementation and plenty of examples of its use.
What I want to talk about here is the presentation style that I used for the code camp. I recently read on The Register about a study that showed that when you present the same information orally and textually (i.e. your power point slides just repeat what you’re saying verbally) that this confuses the brain. Since this was a code camp and not a lecture series, I decided to forego any use of powerpoint or slides altogether and just show everything “live” in Visual Studio.
I took the “minimal” Direct3D application that I used in my book as my starting point. It does all the usual things: register a window class, create a window, create an IDirect3D9 interface to then create an IDirect3DDevice9 on the window and render a triangle. Its all pretty simple and it has the usual style of error checking that you see proliferating on the net and in the Microsoft sample code. Your code is littered with if statements and a cascading of return error status codes to unwind yourself from the innermost place in your code back out to the return value for the process when it exits. Its pretty standard stuff and its also pretty disgusting. Your code is littered with control structures that are irrelevant to the task at hand and are only there to provide for an error path that bails out of continuing the calculation.
So with my Visual Studio in full screen mode and a large font selected for the text editor to make the code legible anywhere in the room, I started to go through the process of modifying that “standard” but ugly code and turning it into something better. I recreated my error handling framework piece by piece as I reworked this minimal application into one that had not only better error handling to replace the existing error handling, but more error handling than it had in the first place. I demonstrated how you can unify the different sorts of error codes that appear in the Win32 world: COM HRESULTs, Win32 functions that return zero on failure and rely on GetLastError to give the specifics, and Win32 functions that return zero on success and the specific error code on failure.
I haven’t yet found a way to be able to treat all of these functions identically in that you have to know which of those three categories contains the function you’re calling. However, once you identify the category I can give you a tool customized for each category that lets you treat them identically after that. Its a pretty handy mechanism, but it is an example of why C++ coding for Windows requires you to “know more” than .NET coding for Windows. With .NET, these details have been unified into a single exception handling model making the .NET API more consistent than the Win32 API. But hey, the Win32 API has been around for a long time and the .NET API has only been around for a few years. Give the .NET API a little more time and things may be different :-).
So my presentation consisted entirely of modifying this code live in Visual Studio, compiling it, and running it to show off the error handling framework. Fortunately for me, I can type relatively quickly so it wasn’t hard to do this as a presentation of live coding. It worked out that what I wanted to show live in Visual Studio was accomplished in just the amount of time I was alloted to give my presentation. I was very pleased with how this worked and will use this technique at future code camps as much as possible.
Legalize Adulthood! 
Leave a comment