Exception handling in Swing Gui

Question

I have an app with a (class) structure sort of like this:
Application
.contains JFrame
..contains 'View'
...contains JTable
....'contains' TableModel
Among other things but that's the important bits here.
When I update a field in the table the setValueAt method in the TableModel is called and updates a database via JDBC. This all works fine as long as everything goes well, but if there's an SQLException , I'd like to pop up a modal errordialog with the exception message. Question is, how do I do that best? It would of course be preferable to have a catch somewhere higher up that above chain but from what I've seen while searching the archives, it's not an easy thing to do that in a gui (Event dispatching thread voodoo or something) so I might have to do try and catch in the tablemodels for each different table? If so, how do the tablemodels get hold of the JFrame object so they can pass it to the dialog to make it modal? Right now I'm passing the JFrame to the Views, which pass them to their Tables, which pass them to the TableModels etc etc and it seems like there should be a more elegant way of doing this.

Answer 1

Since only the logic of the TableModel can generate the exceptions, there's no way to catch them at the JTable, I don't think.
If your TableModel "knows about" its JTable, how about something like:
  JTable myTbl = theModel.getMyTable();
  Container p = myTbl.getParent();
  while (p != null && !(p instanceof Frame)) {
    p = p.getParent();
  if (p instanceof Frame) {
    JDialog dlg = new JDialog(p, "SQL ERROR!", true);
  } else {
     * OW!  How can we NOT be in a containment hierarchy?
     * Do something appropriately drastic here...
  }Whether you do the "upwards crawl" every time you catch an exception, at create-time, or once and then cache, is an optimization that depends on how often you expect to hit errors.
Another option is to have your TableModel implement an "ExceptionListenerList", kinda like the TableModelListener. Then you could have more than one entity listening for the exceptions you're hitting. Somewhat more elegant than having the model know about a single owner.