Another developer recently asked me when try/catch blocks should be used in asp.net applications.  In most apps I write, I try not to pepper these statements throughout the code, but rather deal with exception handling on a global level.  The less code you write, the less code you have to maintain.  In my opinion, there are generally only two reasons to use try/catch statements: Either 1) you need to perform some action if the try code fails, or 2) you want to provide a more user-friendly (i.e. maintenance-developer friendly) error message.  Beyond these two cases, all unhandled exceptions can be dealt with on a global application level.  

For global exception handling, I prefer to use the open-source project ELMAH, which provides logging, notification, and UI functionality by simply plugging it in.  ELMAH performs this magic by using an http module to catch unhandled exceptions, combined with an http handler to display those logs via a UI.  However, if you don't want to use Elmah (stop being stubborn - it isn't that hard), you can always just put your exception handling code within the Application_Error method in the global.asax.

As for the two cases where try/catches should be used:
1) You need to execute some code if something fails.  Transactions are a good example - if you have a workflow that requires multiple steps to be completed within a transaction, and the first step fails, you will want to use a try/catch to perform a rollback within the finally block.

 

2) You want to provide an "English" error message.  Often-times, .net exception messages are fairly generic and don't always tip the developer off as to why something failed.  In these cases, you can catch the message and throw a new one that provides a more readable message.  Note that when you do this, you should always pass the caught exception to the constructor of your new exception - this way you won't lose the stack trace.

There's been a big industry focus on test driven development over the past few years.  Many advocates of TDD make it a point to say that TDD is not really about testing, it's about design.  Writing tests before application code forces you to think about the goal(s) of the application code.  For example, what should the input to a certain method be, and what output should it supply?  TDD forces you to think in terms of inputs/outputs and code interaction.  What input should be provided to the callee, what output should be provided to the caller - essentially, how will multiple objects (e.g. classes, methods, etc) interface.  

I've recently started practicing TDD a bit, and have found that instead of always writing unit tests with some type of testing framework (e.g. nUnit), I sometimes create a console application that calls certain methods and reveals the output.  Granted, these are perhaps more "integration" tests than unit tests, as I'm using them to view database contents.  None-the-less, it got me thinking about TDD, and the notion that "Test"-Driven development isn't really about tests.  In my opinion, a more appropriate name might be "Client"-Driven Development.  I'm not referring to the clients that pay your bills, but the client portions of your application (e.g. the UI which calls another application layer).  There are clients at every layer of your app - the UI calls one layer, that layer calls another layer.  Each caller is a client, and when writing tests first, we need to think in terms of the "client", what it should input, and what the result should be.

Isn't CDD essentially the goal of TDD?

Abstraction is a powerful concept in software development.  Abstracting away certain parts of an application can heavily reduce develop time and make for a maintainable solution.  One shining example of this is the multitude of Object-Relational Mappers on the market, which abstract away a large amount of details about database interaction.  However, as with most things in life, abstraction's highest value is realized when used in moderation.  

While picking up ASP.NET MVC, I've started to realize the significant abstraction that asp.net server controls provide.  ASP.NET MVC doesn't have the parallel (at this point) to the server controls of web forms.  There are html helpers, but those are a very minor abstraction in comparison.  

Whether using web forms or ASP.NET MVC, one could argue that there are always abstractions that don't pull their weight.  For example, it's not unheard of for developers to use label controls for every message they put on a page.  The label abstraction doesn't provide anything that an html span tag wouldn't.  As another example, html helpers in ASP.NET MVC don't always provide much bang for the buck.  In some cases, it's harder to learn the syntax of the html helper than to simply write the html itself.  Learning how to write the html always applies to web development, the helpers only apply to ASP.NET MVC.

Abstractions can make us lose sight of how something actually works.  I will certainly admit that asp.net server controls have prevented me from learning the inner workings of some html tags over the years.  At the same time, they have sped up my development in many cases.  Whether you use abstractions or not, you should first understand what each is doing under the covers.  This allows you to determine if it is adding value or just tacking on an extra maintenance burden.

All software developers have been there.  You’ve started a new job, inherited legacy code, or been chosen to support an application for which you have not written a single line of code.  You spend hours perusing the code, trying your best to interpret the brain patterns of another developer, as laid out in source code.  “What were they thinking?”  “Why did they use a property there instead of a method?”  “What the heck does this ‘RunProcess’ method do?”  “What is this ‘aXList’ variable used for?”  It is under these conditions that you really begin to see the importance of maintainable code.  Or, consider an even simpler scenario, where you are the developer and the maintainer.  I’m sure I’m not the only one who has looked at my code a month or two after writing it, and not even realized that I had authored it.  When this happens, you’ll be glad you wrote your application in such a way that it is easily understood. 

Read more in the following whitepaper...

WhitePaper-SoftwareMaintainability.docx (138.87 kb)