Scott Stewart

exception handling feedback

In a recent blog post a question was raised about appropriate exception handling (or the lack there of in most cases).

One thing I often try to keep in mind is that it isn’t always possible to look at a given snippet of code, and know immediately if an appropriate decision was made in exception handling. As part of my job, I am sometimes asked to code review and determining if appropriate exception handling was applied can be difficult when reviewing “units of work”.

Exception handling strategy is part of bigger application design decision and picture. There are times when it is clear that a try/finally should be used to ensure that even if something bad happens you are still able to do some cleanup work; like closing a db connection. However, it isn’t always clear that a catch makes sense at this same point unless you know something about the overall picture of a given application’s exception handling. I try to live by a basic rule of thumb that says, leave the exception alone unless I am going to either 1) add some real value to the exception or 2) act as the sink point for the exception. By adding some real value to the exception, it might mean hiding the fact that it was a sql exception. And by sinking the exception it might mean determining how and where to log if appropriate, and/or how and where to inform the user. And these things are not always appropriate to do at every section of code that might be doing something dangerous.

It is sometimes by design that a unit of work (a given method, object, etc) does not handle something that appears to be screaming for some exception handling. For example, if all data access code takes place within the context of a data executer component, then a catch statement at the line of code that is doing some sql stuff in the object being executed might be inappropriate. It might be inappropriate because the executer might be handling the exceptions in a bigger more global way and could be adversely impacted if it doesn’t catch the sql exception. Just a small specific example, but the idea is that it isn’t always appropriate to catch exceptions at the point that it looks obvious that something dangerous is taking place.

Additionally, it can become quite expensive to catch a particular exception and just turn around and throw/re-throw the exception with little or no new additional value added to the exception. Especially if this is done multiple times before something really useful is done or before the user is informed that what they were trying to do failed.

tiers and services

When I started this blog, it was because I was working on an article (or blog post) that was supposed to be a IMO a level headed look at some of the silliness around the usage of Web Services in places that it just doesn’t make sense. Places where it doesn’t make sense to cross a boundary and places where a boundary cross is required, but web services don’t fit the bill. Don’t get me wrong; I LOVE web services, SOAP, XML, the new WSE2.0 enhancements, etc. I truly love this stuff. However, I truly love motorcycles too, and when I’m in my living room and want to get a cold one from the fridge, I usually don’t use my motorcycle. One could argue that I could (and in deed I could), but that would just be silly and my wife and kids would probably have me committed to a padded room.

I never finished this article or blog post. Its summer, I have a tight project deadline, and well the topic really deserves serious reflection (not System.Reflection but Brain.Reflection) Today, I read a blog post entitled Middle-tier hosting: Enterprise Services, IIS, DCOM, Web services and Remoting by Rocky Lhotka that blows away anything I could have thought of doing myself.

Rocky, thanks for cutting through the hype. IMO this blog is essential reading to anybody that actually wants to think level headed about the situation. Although, I’m willing to bet that it will generate some additional hype of its own ;-)

There is a lot of silliness taking place today. In my spare time, I try read articles and converse with other developers and architects on this same topic. It seems that everybody wants a silver bullet, and is constantly looking for a single elixir that will solve all aliments. As soon as the covered wagon pulls into town, we try to gulp up what is being sold as a cure for all our problems. In an attempt to do so, our logical layers become tiers, and our single answer for connecting these tiers is web services. I fight this battle on a daily basis with people I work and converse with.

The best elixir is design your application with the technologies that make sense for what it is you are doing. This implies that you first describe and understand what it is you are doing, and don’t pick the technology, protocol, etc. to do this until then. As is stated in the article, maybe tomorrow Indigo or something else will change this. But for today, the point at which my application uses or consumes a web service will be when it needs to interface with another application. While this approach may sound antithetical to SOA, it really isn’t. That is, if the application I’m building is one that’s purpose is to provide a new service and added value to other existing services. It’s all about what it is you are building, and more times then not I’m building an application that may or may not have some service interface points, but should not have it’s internal tier’s interfaces (both logical and physical in some cases) be dictated by web services and therefore SOAP and XML.

.Net Express Editions - general thoughts

I probably shouldn't concern myself with such thoughts or waist anytime over it, but the Express thing has been bothering me and the more I think about it the more it bothers me. First, I fully realize that it is just a marketing thing. An attempt to get more people interested in .Net by reaching a larger or new audience. I'm fine up to this point. I think expanding the overall usage of .Net is good for all of us that make a living by writing .Net code.

My problems however, begin as soon as I browse to the Express home page. The first thing you read is that “The Express products, expanding the Visual Studio product line to include lightweight, easy-to-use, easy-to-learn tools for hobbyists, enthusiasts, and novices who want to build dynamic Windows applications and Web sites.” Ok, stop, hold the press. We have reached the first problem; hobbyists, enthusiasts, and novices should want to learn to build dynamic Windows applications and Web sites. Sure, the word learn is in this paragraph but its purpose here is to state that the Express tools are easy to learn. Unfortunately, this first paragraph has taken our innocent hobbyists, enthusiast and novices directly from “go” to “building dynamic Windows applications and Web sites” without any learning involved. Very interesting.

Problem number two has to do with the products names. Did we really need to call them “Visual Basic Express”, “C# Express” , “C++ Express” (I smile a little saying this one. I wonder who the indented market for this might be. I might need to download this just to see what it is all about). Couldn't we have just named the entire thing “.Newbie” or something and then have it available in different cool flavors. Just as long as it didn't contain the words Visual Basic Express or C# Express. My reasons for this one has to do with the overall impression of “watering“ down the significance of the .Net platform framework and its awesome development languages. If you look at the technology community as a whole, and step out of the MS centric discussion, the biggest challenge .Net developers have in finding good, high profile projects to work on is the mindset by many that programmers who work in Microsoft technologies are hobbyists, enthusiasts, and novices, and the real developers, the ones that are “really“ proficient at what they do, work in Java, and develop for Linux platforms, etc. I'm afraid that by including the words Visual Basic in the package called Visual Basic Express, and the words C# in the package called C# Express, the marketing group has just helped to “tightly couple” us developers, as skilled and seasoned as we may be with all hobbyists, enthusiasts and novices.

Hey, each of us that is introduced to programing is done so in different ways and at different times in our lives. Some of us are introduced to it initially in college (or even high schools now), others come into it because they have the right mindset and experiment with ways to solve business problems at work. I love writing code for a living, and am very happy that it was introduced to me in my own particular way over the past 20 years or so (Fortran in college in the early 80's, then C, then C++, then VB, and now .Net ) I am fortunate enough to work in a career that I love. If these new Express tools can help others get introduced to something they eventually love, and can help promote and spread the overall usage of .Net then that is a good thing. If businesses think that they don't really need to spend the money on qualified developers because Microsoft offers this VB Express thing that allows anybody to build Windows and Web Applications immediately, then that would be a bad thing. If I get asked at my next job or project interview “Oh, I see that you prefer writing in VB.Net...now is that the Express version or the regular version” then that would be a very bad thing.

The shape of a message

I love using structures to define the shape or type of data returned by web methods. Recently, Rich Turner posted a  blog entitled Exchanging Data - shipping typeless containers stating his thoughts why a dataset is a poor choice for this purpose and that a serialize structure is a better choice; I couldn't agree more.

I've gotten in a habit lately of creating a folder under my web service called MessageTypes, and adding all the structures that will will be returned (and/or used as input) to the web methods. This keeps all the message definitions in one place and easy to find.

I also make a habit of NEVER returning the XML serialized instance of my business objects that the web service is using behind the scenes. I always copy the desired data from a b.o. into one of the just mentioned data structures within the web service before it is returned. At times this might seem like a ridiculous extra copy but this is very important. My business objects used by the web service will change over time, however I want it to be a planned coordinated event when I decide to extend the message and data returned by a web service. So, if my web service is returning information about a customer, and within the web service I load up a customer b.o. to do the work, it might be very compelling (at least at the beginning of a project) and easy to return the customer object and allow XML serialization to to build the message shape based on the object's public properties. This is not good. It makes much better sense to take the time to explicitly describe a data structure that will shape the return of the web method, and take the time to explicitly populate the data structure.