Automatic cleanup of shells on exception

[eeybye]

Hello

I experience that the WindowTester framework closes shells during a test, when that test throws an exception.

My test setup is like this:

Code: Select all

test::setUp() {
  open dialog
}

test:.tearDown() {
  close dialog
}

test::testAddProperty() throws Exception {
  insert something into dialog
  test if it has been inserted, otherwise throw exception
}

test::testOnSomeThingElse throws Exception {
}


I would assume, if my first test throws an exception, then that test case will be interrupted and the teardown is called.
Then setUp is called followed by the next test case etc.

But what I see in the log is the following message:

Code: Select all

!ENTRY com.instantiations.eclipse 1 0 2008-10-07 15:12:00.719
!MESSAGE closing shell [aysnc] Setup Tags

My question is, why does the WindowTester framework close my shell, because I really wan't to do it myself?

The test framework does not only close the top shell, but in fact, the entire application is being shut down.

Code: Select all

!ENTRY com.instantiations.eclipse 1 0 2008-10-07 15:12:00.719
!MESSAGE closing shell [aysnc] Setup Tags

!ENTRY com.instantiations.eclipse 1 0 2008-10-07 15:12:03.339
!MESSAGE closing shell [aysnc] Edit Data Center

!ENTRY com.instantiations.eclipse 1 0 2008-10-07 15:12:06.033
!MESSAGE closing shell [aysnc] Capacity and Change Manager


Or I'm I using it in the wrong way ?

All my test cases inherits from a common test case which has a static reference to UI hence a previous post on this forum:

Code: Select all

   static protected IUIContext ui = null;
   
   @Override
   protected void oneTimeSetup() throws Exception {
      super.oneTimeSetup();
      ui = getUI();
   }


Really hoping for some feedback, because this just isn't right.

[Phil Quitslund]

The short answer is that WT closes shells because, as a rule, the runtime needs access to the Display thread (to propagate the exception) which is blocked when the UI is in a modal context (e.g., a modal dialog is open).

Maybe not the answer you wanted... but does it make sense?

Why do you want to do the tearing down yourself?

[eeybye]

Thanks for the quick response.

Why do I want to tear down ??

I think it gives a better structure of the code if the setUp creates the dialog and the tearDown closes it. Then I'm in control of what dialogs are open and when.
As I see it, the problem arises in the situation, where you have multiple modal dialogs, and you don't want them all to be closed.

In our RCP application, we have the main workbench window, from where you can open another workbench window - the edit window. This window is modal
because we want to user to stay in that window while editing. This gives a problem, as we from the modal workbench window also can open modal dialogs.
It might not be pretty, but thats the way it is.

Another issue is, when closing the modal workbench window, the user has to answer whether to save or cancel the changes. I don't know where to put that code
if WT closes the window for me.

To be honest, I didn't know that WT closes all modal dialogs/shells upon an exception, so with this knowledge I might get it working - besides the last issue, which you perhaps
can help me with.

Just another question. Is tearDown being called even if WT closes modal dialogs upon exception ?

[eeybye]

Brief update.

Created an example where I didn't use the tearDown for closing dialogs, but did that in my test functions. Is probably the right way of doing it.
But I came across another strange issue. On what information determines WT what shells to close ??

In my simple test, I just opened the main application - non modal workbench window, entered a preference page and provoked an exception.
The result was, that WT closes the preference dialog but also closes the main application workbench window. How come ?

Code: Select all

!ENTRY com.instantiations.eclipse 1 0 2008-10-07 21:05:13.342
!MESSAGE closing shell [aysnc] Preferences

!ENTRY com.instantiations.eclipse 1 0 2008-10-07 21:05:13.397
!MESSAGE closing shell [aysnc] Capacity and Change Manager

Capacity and Change Manager is the main workbench window.

[Phil Quitslund]

On the surface, that doesn't sound right!

Could you consider sending in a bug report?

Thanks!