C# Flips: Throw Exceptions More than Catching Them
This image of Songhay.Data.Web summarizes the data access layer for the Songhay Web schema. At the risk of embarrassing myself in the glow of Rockford Lhotka, I’m calling my little assembly here “Service Oriented” in part because the file CommandHandler.cs implements a public interface—all the other files contains definitions with internal or other non-public members. There is only one way this assembly communicates with the outside world: through this interface. This one-way-ness is what makes it service oriented.
Where Rocky and rasx() begin to dramatically diverge is when we discover that my interface, ICommandHandler, demands that you emit XPathDocument types exclusively. This demand seems like forcing your developers to write everything that returns Object. Silly, huh? But this silliness is not the subject of today’s Blog entry. Today let’s look at the *.cs files under CommandHandler.cs in our picture. All of those files contain procedures that throw exceptions—there is no exception handling “framework” of any kind in there.
The implication here is that whatever ‘thing’ implementing ICommandHandler out there is responsible for handling any exceptions coming out of the boundary defined by this contract. It seems like a great idea right about now… This is a complete turn from my previous, nascent approach to .NET when I labored for hours and hours under the assumption that a super-cool exception handling framework must be in place before any real work can be done. This was paralyzing to me.
The new (to me), looser idea is that whatever ‘thing’ implementing ICommandHandler out there is responsible for frame-working exception handling. Now some of you kind friends, who are still reeling at my silliness, may ask “How can you just throw exceptions when you demand that everything is of the XPathDocument type?” My answer to that great question is more silliness: all exceptions are rendered as XML messages of a de facto standard schema. The silly part is in the Latin “de facto”—no formal schema yet (my priority is for XPath assertions over schema).
What this means is that whatever ‘thing’ implementing ICommandHandler out there is responsible for ‘knowing’ the XML format of my silly little XPathDocument exception messages—without a schema! Not even a SOAP dish! No! Is this too much convention over message standardization? Did I just defeat the purpose of service orientation?
Whatever ‘thing’ implementing ICommandHandler out there can form yet another layer of interoperability with the formal dress of the “real” Service Oriented world. Songhay.Data.Web is designed to access a database that renders XML natively and is supported by System.Data.Common (today this happens to be SQL Server 2005). The impact of this native support for XML may reverberate too far for OOP professionals who would rather work with “pure” objects (Rocky). But (to me) an XPathDocument is not “just like” the Object type. This is similar to saying that JavaScript has no types when it does… The lambda expressions of LINQ may make this entire design moot—even for me.