Thanks Andy, your comments are spot-on. I did end up implementing a local IMessageHandler so I could throw something like an AssertionError. It didn't give me exactly what I was after, but it does improve the visibility of the test failure.
The main issue is a combination of the LTW timing issue you allude to, as well as the way JUnit works. At the time the classes are loaded/weaved, there are of course no actual tests executing, it's before that time. So it's not a simple matter of throwing an exception - in fact, JUnit seemed happy to continue to launch the test suite even when an unchecked exception was thrown. Of course the custom IMessageHandler can easily store high-priority weaver messages and then we can make an assertion on it in test(s). Thanks Brett On Mon, Oct 24, 2011 at 8:53 AM, Andy Clement <andrew.clem...@gmail.com> wrote: > Right now perhaps the option you have here is -XmessageHandlerClass > which is supplied the classname of a type implementing IMessageHandler > - so you can then do what you want for any message that comes out. I > guess you could use the type name of the THROW class if you wish, > likely to be something like "org.aspectj.bridge.IMessageHandler$1" (as > a workaround for it being non 'top-level' at the moment). > > I think I raised a bugzilla already for another approach I was > thinking of, where you annotated the advice/pointcut with expectations > (I expect it to match X number of times) and errors will be thrown if > the expectation isn't met. This is more straightforward with compile > time weaving though as you know when that has finished - it isn't so > obvious in LTW when it has reached the point where the expectation > should have been met. (there may still be more types to be loaded). > > cheers, > Andy > > On 22 October 2011 20:54, Brett Randall <javabr...@gmail.com> wrote: >> Hi, >> >> When unit testing aspects and advised test/tested code (as opposed to >> deploy/runtime, where this option wouldn't make sense), it would be >> nice to be able to instruct the weaver to throw some sort of unchecked >> Exception or Error if there are configuration problems with error >> severity or higher. Does such an option exist - I couldn't see it in >> the LTW weaver options? >> >> This would allow unit tests to fail-fast in the case of a LTW >> configuration error, and could help clarify the cause of the failure. >> Some pre-existing unit tests I'm currently working with picked up some >> weaving issues during development e.g. a typo in a pointcut, and the >> program continues to execute, and to establish the cause of the unit >> test fail you need to read the weaver verbose console messages to find >> the problem, whereas an exception would be clearer. >> >> Has anything like this ever been considered - would it be feasible and >> worthwhile? >> >> Thanks >> Brett >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users