Brennan’s Blog

In response to the freshly coined ADD methologies I decided to assemble the following list of custom exceptions for the real world. I do not recommend using them, but sometimes I come across code and I wish I could just throw one of these exceptions.

LegacyCodeException

Sometimes you run across a class that is thousands of lines long with most of the work done in a single public method. It may even use several member variables all over the place so it is hard to keep track of everything as you look through the code. When I have to update code like this to add a new feature or fix a bug I wish I could just wrap it in a try...catch block and if it catches an exception I would like to re-throw it inside of a LegacyCodeException.

MisleadingMethodNamesException

Other times I have come across method names which do not really reflect what they actually do because the code has changed so much since it was first created. As a result staring at the code for hours does not help with understanding it. And some of these methods do not follow naming conventions such as using verbs for method names and occasionally combining the verb with a noun such as Execute, Split or FindControl. Sometimes the method names are completely non-descriptive or extremely misleading. In this scenario it would be tempting to throw a MisleadingMethodNamesException.

JobSecurityException

Some code is just overly complex and you swear it was complicated on purpose for the sake of job security. In this case it would be funny to call a fish a fish and throw a JobSecurityException.

DoesNotWorkHereAnymoreException

There is also code that was written years ago that conforms to old coding conventions that does not leverage modern language features that you cannot imagine living without. Collections without generics comes to mind. When you come across this old code you cringe as the sight of it. And when you want to ask the original developer to walk you through it you can't because they no longer work there.

NotMyCodeException

There are other times when you know all of the original developers are still there but nobody wants to claim responsibility for the code and explain how it should work and how you should maintain it.

LostInTranslationException

I once worked on a bit of code that used an API for a third party product that was translated from C to Java. It completely ignored the object-oriented conventions of Java. It took my brain a while to completely wake up and realize I should read the Java code as if it was C so that I could understand it. And despite working with a stable framework (.NET) we still deal with multiple languages from C# and VB to Javascript and T-SQL. Getting the intent across is not as simple as it should be.

Of course the proper way to deal with these common problems is to refactor the code to reduce the code complexity (see cyclomatic complexity) and name the methods according to their function. And for those methods you want to eliminate you can add the Obsolete attribute to them so it generates a compiler warning but still compiles and runs alright. Eventually you can safely remove those methods. And once the code is cleaned up you should make sure there are enough unit tests to provide sufficient code coverage.