Evils of debugging tiered software

Typically, one of the payoffs of a tiered MVC designed application is ease of maintenance. I'm not so sure awhen it comes to debugging. If you are familiar with the application architecture and the application is consistent in how it models objects then the debugging is easier.

I just spend about 3 hrs trying to solve a bug that i introduced while refactoring. I am refactoring some code in a pair of collaborating objects a listener and a service .

I am moving bus. logic from the listener into the service. My listener instantiates the service in its configure method. I created the problem in the one of the service functions, but the error was being reported by CF in the listener constructor at the line number where the instantiation to the service was being called. Eventually, i was able to track the error down in the service function that was using the same variable name for both an argument and a locally vared variable. The error was reported correctly but it took me way too long to figure out that the reporting of the error in the listener constructor was caused by a function in the service. Seems obvious in hindsight, that the listener constructor was failing because it was creating the new object that had to parse the entire cfc before it would create a new instance of itself.

Moral - if the error is occurring in a constructor or init function, then look carefully down stream into the instantiated objects.