Community
Participate
Working Groups
In general that's probably good, however I've encountered a case when it actually does not allow to test actual application behavior: 1. An application has a bug in a handler for context menu 2. Application has a custom Exception handler dialog, which is shown via CustomWorkbenchAdvisor.eventLoopException 3. During recording, exception happens and user can record interactions with Error dialog 4. During replay, exception is caught and logged in AUT workspace log. Test case fails because it cannot find a dialog
One of possible "potentially safe" solutions I see is to use the same logic as for exec-with-options -allowStatusDialog: 1. When we record an interaction with window, we should understand that it appears because of unhandled event loop exception 2. If user interacts with this window, we should record exec-with-options so that during replay these exceptions are not being caught by our runtime But maybe more correct behavior would be to throw away our exception catch logic, as it potentially hides unexpected internal errors. By the way, it is unclear why status dialogs appear when exec-with-options is turned on, as status dialog are shown through default WorkbenchAdvisor
By the way, there is an unnecessary duplication and inconsistency across SWTEvents#sendEvent(SWTUIElement w, final int event) and SWTEvents#sendEvent(SWTUIElement w, final int event, int x, int y) -- the second one does not catch all exceptions, it catches only SecurityException and IllegalArgumentException. Why?
