I have voiced my concerns in the past about maintaining and growing code that uses AOP. I am not one to quickly shun a technology and never look back. I constantly review technologies.

I was reading this paper on recovery oriented computing (ROC) which is in line with my autonomic persuits and they mentioned FIG. FIG is fault injection in glibc. If you've ever tried to set up a networking test where write() would block long enough to see the impact without massively mutating your code, FIG (or its concept) would be something to look into.

When I read about FIG, the little 10W light blub in my head flicked to a dim glow. Use AOP to do fault injection!

Unit testing, even if the developer of the unit test is not the developer of the code being tested, is of limited use. No matter how hard we might try, unit tests tend to be parallel to the concerns of the code rather than orthogonal. In other words, unit tests tend to miss many of the bugs that aren't directly in line with the use / purpose of the code. For example, if you have a class that reads data from the network and writes it back then the unit tests are typically going to align themselves with that -- they will ensure that stuff in matches stuff out. But what about the orthogonal concerns, most of which involve difficult to trigger network concerns? (Yes, I'm horrible at giving motivational examples.) Attempting to write code that will cause exceptions to occur is likely to require a harness that's bigger than the original code and test combined. And how do you guarantee the validity of the harness? In other words, who tests the tests? The coast guard? I don't think so!

Using AOP (or just java.lang.reflect.Proxy) to inject faults will allow you to test the corner cases without a massive harness and without changes to your existing code or unit tests.

On a parallel note, this article brings up some interesting uses of AOP for exception handling.