SwingWorker and exceptions in the doInBackground method

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I have this long preprocessing task in a Swing app I’d like to be done
in the background, so I am working through
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html.

As I understand it, the method doInBackground in SwingWorker is not
supposed to do anything with the GUI. However, what I do in there may
throw exceptions, which I’d like to handle with error messages to the user.

Is it OK to have stuff like

} catch (final UnsatisfiedLinkError exc) {
JOptionPane.showMessageDialog(UIBuilder.this.getFrame(),
"The Mona library has the wrong format. You may be on an unsupported
platform. "
+ "Try compiling the library yourself or contact a developer.",
"Mona library problem", JOptionPane.ERROR_MESSAGE);
exc.printStackTrace();
}

in the method, or will this cause problems?

If not, then how am I supposed to give the user some feedback about what
went wrong?

TIA, H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFILCxle+7xMGD3itQRAmQ+AJ0RlU38LQqO67lm/Hdueuiiap2DAQCeP/xO
lIVQ15nUVAnrdVokDihH5yo=
=wVF7
-----END PGP SIGNATURE-----

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt Humphrey schreef:
| |> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi,
|>
|> I have this long preprocessing task in a Swing app I'd like to be done
|> in the background, so I am working through
|> http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html.
|>
|> As I understand it, the method doInBackground in SwingWorker is not
|> supposed to do anything with the GUI. However, what I do in there may
|> throw exceptions, which I'd like to handle with error messages to the
|> user.
|>
|> Is it OK to have stuff like
|>
|> } catch (final UnsatisfiedLinkError exc) {
|> JOptionPane.showMessageDialog(UIBuilder.this.getFrame(),
|> "The Mona library has the wrong format. You may be on an unsupported
|> platform. "
|> + "Try compiling the library yourself or contact a developer.",
|> "Mona library problem", JOptionPane.ERROR_MESSAGE);
|> exc.printStackTrace();
|> }
|>
|> in the method, or will this cause problems?
|
| There are only a couple of methods that can be called off the EDT
| (revalidate, invalidate, repaint)
|
http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html#exceptions
| It's not longer advisble to create GUI in the non-EDT thread.
|
|> If not, then how am I supposed to give the user some feedback about what
|> went wrong?
|
| For whatever method you use to perform a GUI update, simply invoke it
from
| SwingUtilities.invokeLater (). For your example above, write a method
for
| handling the exception (or exceptions in general) like this:
|
| private void handleException (
| final Exception ex, final Frame parent, final String message) {
| SwingUtilities.invokeLater (new Runnable () {
| public void run () {
| JOptionPane.showMessageDialog(parent, message,
| JOptionPane.ERROR_MESSAGE);
| ex.printStackTrace ();
| }
| });
| }
|
| The EDT will then pick it up and run it. If your task is finished at
that
| point it can simply exit as it normally would. The user will get the
| message. If you need the user to control the background task via the
| dialog, invokeAndWait will block until the dialog portion has finished.

Thanks Matt, this is as I thought, only that I would have needed quite
some time to come up with such an elegant solution. This really is the
great benefit of communities like this one.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFILEPXe+7xMGD3itQRAsuBAJ40fzIdEHFkM0Y0k1oDtVPhmp88wACfc86W
6+HecIrRaiRKnd8t81S8bAA=
=9jRK
-----END PGP SIGNATURE-----

 

[RedGrittyBrick]

I have this long preprocessing task in a Swing app I’d like to be done
in the background, so I am working through
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html.

As I understand it, the method doInBackground in SwingWorker is not
supposed to do anything with the GUI. However, what I do in there may
throw exceptions, which I’d like to handle with error messages to the user.

To avoid mixing GUI and non-GUI code in doInBackGround, I generally do
it this way:


new SwingWorker<Void,Void>() {
SomeException pendingException = null;

// Non GUI work goes in here
protected Void doInBackGround {
try {
// something
} catch (SomeException e) {
pendingException = e;
}
}

// GUI stuff here
protected void done() {
if (pendingException != null) {
JOptionPane.ShowMessageDIalog(...);
}
}
}.execute();

For me, the advantage of Swingworker is that you *DON'T* need to use
SwningUtilities.invokeLater() yourself. YMMV.