A couple years ago I wrote about programming with Aspects. From a theoretical perspective, programming with aspects is like combining two different programs into a single program at compile time using coding conventions to link the two together.
A common use of aspects is for tracing code execution or logging errors. For conventional error handling you would implement try/catch, and log errors in the catch. After a while, you find you are writing the same code over and over. Perhaps you write a helper class to call in all the catch routines, to simplify the logging.
With aspects, you are not required to write try/catch all over the place in order to implement error logging. Aspects automatically bind to your method calls at compile time, and extend the method to include necessary error handling. This does not mean that you won’t have any try/catch routines yourself. However, how you handle the catch will most likely be throwing a new error with more meaningful information.
Aspects work by defining a type of code you wish to associate with your program. Logging is a good example. They are implemented at compile time with a pre-processor. The pre-processor looks at the aspects, finds the kinds of code patterns they wish to attach, and merges your source code with the aspect code. Then the compiler calls the newly merged code, containing both the original source, and the extensions contained in the aspects, and compiles it as if you wrote the code that way in the first place.
Talk about a lot of time savings. One popular aspect tool has been out there since 2004, called PostSharp. That would be a good place to go if you aren’t yet familiar with aspects, and want to learn more.
Cheers,
Ben