Community
Participate
Working Groups
AK (8/30/2001 12:43:40 PM) drag'n'drop swallows all throwable which makes it very hard to debug. all you see is that some things just do not work as expected. after debugging you find out that it's an NPE or something like that. i guess checked exceptions can be swallowed silently, but the unchecked ones should be at least logged NOTES: VI (30/08/2001 7:41:02 AM) This is a tough one. If an exception is thrown it will hang the drag and drop operation. If the exception is to be logged, where can it be logged and how will the application know there is an exception log to check. AK (9/25/2001 3:00:51 PM) maybe take some callback object that you'd notify that something went wrong (?)
was incorrectly assigned to me
PRODUCT VERSION: 133
Why will the exception hang the DND operation? Can't the cleanup code be moved inside a finally{} block as opposed to a catch{} block? Please provide a case where using finally or rethrowing the exception would cause DND to hang.
Agree. SWT should NEVER be silently catching exceptions.
Can we look into the particular hangs and GP's to see if there's another way to fix this?
*** Bug 14715 has been marked as a duplicate of this bug. ***
Will revisit after R2.0.
Post 2.0. Re-opening bug reports for review.
*** Bug 51439 has been marked as a duplicate of this bug. ***
Possible change to OleEventSink.Invoke: asynchronously re throw the exception so that we don't die silently as in bug 57068 something vaguely like: try { notifyListener(dispIdMember,event); } catch (final Throwable t) { widget.getDisplay().asyncExec(new Runnable() { public void run() { SWT.error(SWT.ERROR_FAILED_EXEC/*whatever*/, t); } }); }
The reason that OLE is "eating" any exceptions thrown by the application's event handlers is because failing to "eat" the exception results in a General Protection Fault. When a callback comes in from the OS, the java code is run which notifies the listener and in some cases this results in a Java exception. The exception kicks you back out into the c code of callback. The exception can not be thrown in Java until we return to the original call out which is usually Display.readAndDispatch but it could be any number of JNI calls including COM.DoDragAndDrop. The reason OLE has a GPF is because until we return back to the original call out, callback notices that there is a pending exception and returns 0 without calling the Java code. In OLE, S_OK = 0. Returning S_OK means that the callback has performed the actions asked of it which may include providing a valid pointer to data. Failing to provide a valid pointer when you said you have may result in a GPF (depends on how cautious the activeX control is). Instead of the proposal in comment #10, we are considering adding API to callback.c to specify the return value in the error case. For OLE the error code for failure is E_FAIL = -2147467259. The difference between this solution and asynchronously throwing an error is that returning the value E_FAIL lets the ActiveX control or the system drag and drop mechanism know that things are not good and take its own corrective action.
The stacktrace needs to be available. Maybe this would mean logging it to stderr or a pluggable output stream (such as the runtime log).
The stacktrace will be available because the exception will be thrown just like an exception that occurs in a normal event handler (e.g. MouseDown, KeyUp)
Fixed in HEAD for 3.1 M4.
