Sian January wrote: > I wouldn't necessarily recommend doing a lot of this kind of logging with > aspects as it can make quite a messy aspect and the pointcuts can be quite > fragile (i.e. minor changes in the code can easily cause a pointcut to stop > matching). But it is possible. My second suggestion is a little more > robust and you may find that that advice could be applied more > generally anyway (e.g. 2, 3 and 4 could be logged after all calls to > performHandshake instead of just calls from MyClass.dataExchange).
I agree, but would also point out that: - putting the explicit logging calls in the implementation clutter the 'business end' of the code; keeping logging separate like this makes it clearer what each part of the code is doing. - we can reduce logging code duplication by defining pointcuts that apply to numerous places. - logging becomes trivially turn-off-and-on-able. - if you have decent IDE support, like AspectJ, you can see where the logging calls are being applied and develop them quite 'naturally'. and the usual caveat, that I'd suggest we only use aspects sparingly like this, and don't start going crazy. If a vi user only misses out seeing a few logging calls (without looking through the aspects list) that is acceptable IMHO, but if there is any functional change missed then that is unacceptable. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
