Unhandled Exceptions

I ran an easy few miles this afternoon as my final run before the Great Race. I had wanted to avoid hills, but given the geography of this area, that’s pretty much impossible. I ran the 5K loop up to the church and through the park. I felt pretty good, and my time wasn’t all that bad (averaged about 8:30 per mile). I’ll probably lift tomorrow (maybe a little cardio, but no running).

Work has been rather hectic. I have an awful lot of quarterly objectives that I need to meet in the next three days, so I’ve been kind of busy pushing out new features and wrapping up some of my objectives. I don’t think I’ll have a problem finishing up, but it’s definitely going to be tight.

I have been using Trillian for some time because it allows you to utilize multiple IM clients (AIM, ICQ, MSN, Yahoo) in a single application. However, with my increased usage of Gmail, Facebook, and Twitter, it still seemed like I had too much open to do the same things.

Firefox has some add-ons like Twitkit and the GMail Manager that allowed some interactivity, but that mean that I had to have Firefox open all the time. Sadly, when I’m really focused on development, I don’t usually have that open.

A co-worker noticed my tweet about Twitter’s IM service being down for some time. He pointed me to Digsby, which is the current uber client for IM, Email, and several social networking sites (Facebook, MySpace, and Twitter are the only ones currently implemented). Given my new fascination with Facebook, I thought I’d give it a try. So far, I’m impressed.

The ability to tweet from the IM client works great (better than Twitter’s own IM bot). The integration into Facebook chat means I’m on Facebook chat pretty much all day, which is pretty fun. And, since my various email accounts (2 gmails, yahoo, msn, and a couple pop accounts) are easily manageable within Digsby, it looks like Trillian is out. It’s served me well, but the Digsby client seems much more integrated.

That’s my life in a nutshell. My wife and I put in an offer on a house (on a whim) which they accepted. We’re now in the middle of trying to sell our house so that we can pay for the other house. Yes, our purchase of the new house is contingent on the sale of our current home, so it’s not quite as hectic as it possibly could be.

What’s that mean? Well, my days are spent fixing bugs (and implementing features) in our new product in preparation for a release within the next month or so. My nights and weekends are filled with cleaning and fixing our current house. Our townhouse is only three years old, so it’s in wonderful shape, but there are some touch-ups here and there that need done (some drywall patches, a few paint touch-ups, and general top to bottom cleaning).

I’m getting a little burned out at this point, but hopefully we can sell this place and get into the new house before Christmas. Our fingers are crossed.

It would have to be like this. I guess there’s just something fun about having a waterfall in my computer… Although does that mean I would have to pee a lot while working?

I spent the better part of a day last week trying to reconfigure our application exception handling. With our switch to a WCF service, our business layer’s method of throwing exceptions for validation problems or as warnings became a bit, well, annoying.

I actually thought I had a solution: Have the WCF service include error details. What that does is send back a SOAP FaultException (System.ServiceModel.FaultException<T>), where T is a System.ServiceModel.ExceptionDetail). From there, I could examine the ExceptionDetail and detemine what type of exception was thrown and handle it appropriately. All well and good, although throwing those exceptions around makes the service somewhat vulnerable, since users can use exceptions to glean information about the system.

I could live with that, except for the fact that my system didn’t work in partial trust. Why? Because System.ServiceModel.ExceptionDetail is not serializable in partial trust (one of its properties doesn’t have a setter or something). So it was back to the drawing board.

A Google search or seven led me to Guy Burstein’s blog post about WCF Exception handling using Microsoft’s Enterprise Library and it’s Exception Handling Application Block. Basically, the MS Enterprise Library has some classes that allow me to automatically wrap and generate a SOAP FaultException with any internal type (T from above) that I want. That means that I can return the data that I want AND I can filter the exceptions as I wish.

It’s a pretty slick system, but getting it working tooks some time. I think most of my time dealt with little idiosyncracies, like where the classes are defined, how the application block is configured, etc. One thing I will not for posterity is that your fault class (The class you want to go into the SOAP exception) cannot be a “class within a class.” I couldn’t figure out the proper full name for that, and it ended up giving me headaches. So I moved the class to the namespace level, and everything worked ok.

I’m not going to repeat all the steps, as Guy’s blog does an excellent job of describing the steps. Once I get some time (ha!), I’d like to look into the automated logging of the exceptions, as I think that would be extremely helpful.