A few months ago there was a series of posts on the FxCop blog about the FxCop rule "Do not catch general exception types." These posts generated some lively debate about how strictly this rule should be enforced. I found it quite interesting to read the arguments from both sides on whether or not "catch(Exception)" should EVER be used. I will post my own opinions on this issue in the future. However, one comment in particular stuck out to me:
Of course you're correct that deployed applications that crash frequently shouldn't be deployed. However, there are many circumstances that lead to this happening anyway.
It's not all dev teams that have a user base and budget as large as MS's that allow it to do something like have a public beta, that is very close to final functionality, in front of thousands of users, for months, as MS have done with Visual Studio. Even after all the CTPs, betas, RCs, etc, there are still plenty of bugs found pretty quickly in VS 2005.
In our situation, the cost of taking the user's time for testing (in terms of the value they're not adding by doing their job) is far greater than the cost of development time. This leads to a business that has a low level of interest in providing much help in terms of serious testing. The cost of the software being late one day is much greater than the cost of a day of development.
Of course, the end result is less quality. So as much as we'd like to have lots of testing, so bugs were few and far between, so we could fail fast when, once in a blue moon, an exception occurred, it's just not going to be the reality. No amount of telling the business "This is not how you write good software" is going to change things.
So while I agree that the Fail Fast method is the "correct" approach, because it precludes invalid state in the application, I'm not sure how realistic an approach it can be for quite a lot of common application dev scenarios where the business controls dev budget/time frame.
So I guess if the rule is still relevant to some cases, then it should be kept, and the rest of us can just suppress it, which always gives me a nice warm fuzzy feeling inside :P
See the post on which this comment was made for more context.
What I found interesting about this comment was that the poster is essentially arguing that the rule does not always apply because business demands sometimes dictate that applications be deployed before they have reached the highest level of quality. I also have some opinions on that which I will post in the future. The point I want to make here is that best practices are always best practices, even when we choose not to follow them. It could be that to get an application out the door with the time and the budget that the powers-that-be have dicatated, you have to cut some corners. But that doesn't mean that cutting corners is the best way to implement the application; it just means that it was necessary in a given set of circumstances,
The documentation for the FxCop rule says "Do not exclude a warning from this rule." I suppose the commenter would have preferred it to say "unless you have to in order to finish your project on time." But that's not the point. FxCop, and other static analysis tools, can only tell us what we should do; it up to us whether or not to do it.