Alex Papadimoulis' .NET Blog

I've come across a truly revolutionary software development methodology called Front Ahead Design (FAD). Essentially, it's a fundamental paradigm shift over "traditional" and "neo" ways of building software. Not only does it surpass every software development methodology out there, it solves every problem there is to building software (and then some). But don't take my word for it, here are the Top Five fundamentals ...

 My post the other day (Computer Programmer Inflation) got me thinking of another type of inflation that I've observed over the years: Comicality Inflation. Like other types of inflation, it's not as if things have gotten funnier, it’s just the terms we use to describe them.

I was thinking the other day about the changes over the years in what we call people who write computer programs. Back in the day, we called these folks computer programmers. A rather fitting title, one would suppose, for a person who programs computers. But one would suppose wrong.

Shortly after computer programmer became the "official" title, someone, somewhere, somehow decided that it wasn't enough. After all, computer programmers do more then program, they analyze a problem and then write a program. They should, therefore, be titled programmer/analysts. One would suppose that such analysis is an implicit part of the job, much like how writers need to think about something before they actually write it. But one would suppose wrong.

Unlike the computer programmer title, programmer/analyst seemed to stick around for quite a while. In fact, it was only fairly recently that we all became software developers (or, developers for short). The change this time around was all about image; you gotta admit how much sexier developer sounds over programmer. Certainly one would suppose it's pretty hard to "sex up" an industry whose Steves out number its women (see the Steve Rule). But one would suppose wrong.

Believe it or not, developer is on its way out and we're in the middle of yet another title change. If you think about it, the problem with developer is that, if any one asked what a "developer" is, you'd have to expand it to software developer. Software == Computers == Programming == Nerdy. We can't have that!

This is where the title solution developer comes in. We're the guys who you call when you have a problem. Doesn't matter what the problem is, we will develop a solution. Heck, we can even develop solutions (by programming a computer) for problems that don't exist. We're that good.

But where do we go from here? First, we need to reach the maximum level of ambiguity possible. I'm not an expert at coming up with job titles, but I suspect solution specialist is a step in the right direction. Of course, once we've gone all the way to one side, the only place we can really go is to other extreme: a way more overblown/descriptive/nerdy sounding name than needed. When solution specialist (or whatever) expires, I really hope the replacement will end with -ologist. I would really like to be an -ologist of some sort. You know you'd like it, too.

Yesterday on The Daily WTF, I mentioned something I called the Steve Rule: in a random sample of programmers, there will be more named Steve then there will be females.

Thought I'd share my review of James Avery's latest book ...

In this Community Server tip, I'll describe how to make a quick & easy home page that displays posts from one or more forums on one page.. If you're concerned that new visitors to your community will be turned off by the default listing of forums when they go to www.YourSite.com, then this just may be for you. I think you'll find that most of the time you spend on this tip will be in the actual design of the home page. This is what I do for TheDailyWtf.com.

I think that there's a general consensus out there that Exceptions should be limited to exceptional circumstances. But being that "exceptional" is a rather subjective adjective, there's a bit of a gray area as what is and isn't the appropriate use of Exceptions.

Let's start with an inappropriate use that we can all agree too. And I can think of no better place to find such an example than TheDailyWTF.com. Although that particular block of code doesn't exactly deal with Throwing exceptions, it is a very bad way of handling exceptions.

To the other extreme, exceptions are very appropriate for handling environment failure. For example, if your database throws "TABLE NOT FOUND," that would be the time to catch, repackage, and throw an exception.

But it's in the middle where there's a bit of disagreement. One area in particular I'd like to address in this post is exceptions to business rules. I mentioned this as an appropriate before, but noticed there was quite a bit of disagreement with that. But the fact of the matter is, exceptions really are the best way to deal with business rule exceptions. Here's why.

Let's consider a very simple business rule: an auction bid may be placed if and only if (a) the bid amount is higher than the current bid, (b) the auction has started, and (c) the auction has not ended. Because these rules (especially b and c) are domain constraints (i.e. they restrict the range of acceptable values), they are best handled by the Preserver of Data Integrity (some call this the "database"). To accomplish this validation, we'll use a stored procedure with an interface like this: procedure Place_Bid ( @Auction_Num char(12), @Bidder_Id int, @Bid_Amt money )

Now let's consider the layers of abstraction it actually takes to go from the user clicking the "Place Bid" button to the stored procedure being called:
•PlaceBidButton_Click()
•AuctionAgent.PlaceBid()
•IAuction.PlaceBid()
•--- physical tier boundary --
•IAuction.PlaceBid()
•Auction.PlaceBid()
•AuctionDataAgent.PlaceBid()
•SqlHelper.ExecuteCommand()
•--- physical tier boundary --
•procedure Place_Bid

Without using exceptions, it gets pretty ugly passing the message "Bid cannot be placed after auction has closed" from the stored procedure all the way back to the web page. Here's two popular ways of doing this:

• Return Codes - Have every method that could potentially fail return some sort of value. True/False is the most common but rarely provides enough information about the failure. Our PlaceBid function would need four different return codes: Success, Fail-LowBid, Fail-EarlyBid, Fail-LateBid. Of course, this technique fails when your method may need to actually return something other than the return code.
• Class Level Checking - For each of classes, add property called "LastError." This will contain an Error object that contains information about the last error (if one occurred). Simply check it after each operation.
• Output Params - Add an out paramter to every method to pass back an ErrorObject. This is similar to the aforementioned technique except it is on the method-level.

In all three cases, you need to manually "bubble" up the message from method to method. As you can imagine, this adds lots and lots of needless "plumbing" code intertwined with your business logic. Since it's at the method level, all it takes is one developer to not code a method to return the right code.

The proper way of handling the Bid exception is, naturally, with Exceptions. When you raise the error in the stored procedure code, indicate that the message is a business rule exception intended to be displayed back to the end user. After that, you only need to put try/catch blocks in two places, the ExecuteCommand() method and the PlaceBidButton_Click() method.

ExecuteCommand() Psedo-code
Try
  sqlCmd.ExecuteNonQuery();
Catch ex As SqlExecption
  If IsUserSqlException(ex) Then Throw ConvertSqlExceptionToBusinessException(ex)
End Try

Oleg "XML MVP" Tkachenko nailed it. I'm a "resource waster" and proud of it.