Joshua Flanagan

If you use Visual Studio.NET and are at TechEd - go see Cyrus (didn't catch his last name) in the Microsoft pavillion of the exhibit hall.  He works on the compiler/IDE team at Microsoft and gives a great demonstration of the new features coming in VS2005.  I had read about the new features, and played around with the pre-release versions a little, so I was already anxious to get my hands on it.  But after watching Cyrus's demo, I can't wait.  The “code definition” window is ingenious.  When you place your cursor on a variable in your code editor, the code definition window displays the source code where the variable is declared.  Not just the definition of the type that you might get in a tooltip, but the actual lines of code (a few before and after) so you get the context of the declaration, as well as any comments, etc.  One of my most used keyboard shortcuts is “Go to definition”.  With this new feature, it will be completely unnecessary.

My development efforts went on a major tangent recently when I discovered there was no “safe” way to dynamically generate an icon in the .NET Framework (using Icon.FromHandle() requires the UnmanagedCode SecurityPermission).  What was supposed to be a very minor feature of an application - updating a tray icon with custom text - turned into a major time sucker.  I was forced to learn the innards of the Bitmap and Icon file formats and write my own conversion code.  Isn't this the kind of coding the .NET Framework is supposed to prevent?  We should be writing business logic, not common image format conversion routines.  I'm not attacking .NET in general, there is no question it has made me more productive, I'm just a little bitter that I got bitten by one of the edge cases. (I have to admit, I enjoyed doing the “low level“ coding for a while, I just wasn't planning on the time requirement)

Anyway, the good news is, I did it, and now it's done.  I wrote the code so you don't have to.  I have posted it as my first ever article on The Code Project.  Check it out and let me know what you think.

“You want to catch the base exception?  You want to catch the base exception?  You can't handle the base exception!”  Ok, Jack never said that.  But he should have.

This is a very important point that hasn't hit home with a lot of co-workers.  I wonder if it stems from the VB habit of handling every error in a single On Error Goto statement (or worse, On Error Resume Next).  I'll admit, I didn't initially buy into it, until I had a good understanding of what it meant.  By catching the base exception, you are explicitly stating that you know how to handle the exception -- even though you don't know why it happened!  If you knew it could happen and how to handle it, you would catch that specific exception type. 

Granted, you need to be able to log the error, so you know that it happened.  That's where top-level “unhandled exception“ events come into play: AppDomain.UnhandledException, Application.ThreadException, and HttpApplication.Error.

For all the details go read Jason Clark's article in this month's MSDN Magazine.  He does a great job of explaining how to properly handle exceptions.  That's what inspired me to write this post.

 

I recently read Coding Slave by Bob Reselman, after having my interest piqued by Rory.  This is a book that every software developer should read.  It is a very easy read, but its message has the potential to be very important to our lives.  It has already had a positive effect on how I approach and feel about my day-to-day job.  Initially, the subject matter may seem depressing, but I think the ultimate message is really uplifting.  After you read the book (or if you aren't conviced to read it yet), go listen to the .NET Rocks episode with Bob Reselman.  Then go read Rory's interview with the author (it has a link to the first part).  At that point, you will probably want to read the book again.

Bob isn't the only coder to write a book about the life of coder.  You should also read Ellen Ullman's Close to the Machine: Technophilia and its Discontents.  This is the first book that I read which confirmed my theory that coding is a personality trait, not a chosen career path.

Wow.  Now this freaked me out.

You see, I got so much out of last year's TechEd, that I couldn't wait to get back.  I've been checking the site regularly for the opening of this year's registration.  Before registration was available, I was already working my management looking for the necessary approvals.  I got the sign off and was all set to go.  But when registration opened up, I got word that I might be able to use one of the complimentary passes provided to my company as a sponsor.  Being a good corporate citizen, trying to save some bucks, I contacted the people that were allocating the passes MONTHS ago.  I made my plane/hotel reservations.  They told me “sure, we might be able to give you one, call back in a month or so”.  So I did.  “We don't know yet, call back in a couple weeks”.  So I did.  “Try again next week, we should know by then.”  So I did.  “We're working on it, we'll let you know.  Don't worry about it, they won't sell out, you can always buy the ticket if you don't get one of ours.”  Okay, fine, but I'm still anxious.  Finally, Friday I sent an email asking for a final answer, I really need to finalize my plans.  Monday I received a reply “sorry, all of the passes have been allocated”.  AAAAHH!  So I quickly log onto the site and buy my full pass. 

And now I find out that 2 days later they sold out!  What's the big deal, the story has a happy ending, right?  Well, yeah, but it's strange when my paranoid, anxious, worry-wart personality ends up working to my benefit.  If I hadn't kept bugging for an answer, I would have missed out - despite having the approval for the funds.  Ouch.  So, thank you, paranoid brain.

By the way, does this happen often?  Does TechEd ever sell out?  I've only been to 2 others (2000, 2003), but I don't remember hearing of them selling out.  Does this mean all of the sessions are going to be really crowded?