[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [albireo-dev] component creation protocol: allow for some hooks
|
Bruno Haible wrote:
Gordon,
Most importantly, they'll also be visible in the error log file which is
more likely to get analyzed later than stdout. This is true whether or
not the error log view is configured.
Which "error log file" are you talking about? Where is it located?
<workspace>/.metadata/.log (for an RCP App).
By letting the exception pass through, it will get handled in a standard
and consistent way by the containing application.
I can rethrow it. No problem.
Unfortunately, you won't be able to re-throw a Throwable without
declaring it in your throws clause. You may be able to conditionally
rethrow for some of the subclasses, but I don't think that is worth the
effort.
I don't think asyncExec catches exceptions silently. It does wrap them
in a SWTException, though. (And I must admit they use a catch of
Throwable :-)).
I just tried it:
- Added an override of afterComponentCreatedSWTThread() that throws
an OutOfMemoryError,
- Verified that I see its stack trace in the console of the Eclipse I use
for debugging,
- Disabled the printStackTrace() in our code.
- Verified that this time nothing is visible in the console,
- Opened the "Error Log" view and found the exception there.
If an OutOfMemoryError occurs and the GUI of the normal user (who does not
have an "Error Log" view open by default) does not show any sign of this
happening, for me it counts as "silent".
But this is not behavior of Display.asyncExec(). It's the responsibility
of code further up the call stack. In an RCP app, that code simply logs
the message to the log file. If the RCP app has the error log view, it
also can be seen there (the view reads from the file, I think).
My only point is that I don't think that low-level library code like
ours should make the decision on how to handle a general exception.
But, I don't object to the configurabile implementation that you now have.