[news.eclipse.tools] Re: Handling exceptions in UI plug-ins

["Mazen Faraj" <mazenfaraj@xxxxxxxx>]

Jeff,
just a quick question here.
Does the ILog instance that is returned by Plugin.getLog() know about the
"isDebugging" flag of it's
associated plugin?

The reason I ask is because I first thought that simply setting the
debugging flag of a plugin to false will prevent a log from forwarding the
events to the registered listeners, but this is not the case
(please correct me if I'm wrong).
So I guess it should be my listener implementation that checks that
pluging's isDebugging state to see
whether or not we have to log.

Another issue is, can I prevent the default platform listener from logging
events from my plugin?
In general, would this be a bad thing to do?
We have our own log listener that does the job, and we don't want to log to
two files
(one will be in our plugin's state area, and the other would be the default
.log file in the workbench's metadata directory).

thanks in advance,
Mazen





"Jeff McAffer" <jeff_mcaffer@xxxxxxx> wrote in message
news:9akooh$h3c$1@xxxxxxxxxxxxxxxx
> Depends on the context. People can put up a dialog if that makes sense in
> their context.  In the platform we often catch and log (e.g., when running
> builders) if the failure is not criticial to the continued health of the
> platform.
>
> It is important that people catch exceptions when they call random code
from
> other (untrusted) plugins.  See ISafeRunnable for some built-in support
for
> this.  This standars support will likely be improved over time as the
kinds
> of problems that come up are better understood.  Blindly catching
Throwable,
> Error and even Exception can be dangerous (e.g. you would not want to
catch
> and ignore OutOfMemoryError).
>
> As for logging, Log is internal but ILog is public.  Each plugin has its
own
> ILog object (see Plugin.getLog()).  ILogs do not map onto files on disk or
> windows on the screen.  They are logical (no pun intended) event
> distribution points.   People do not need to implement ILog, they
implement
> ILogListener and register their listeners with the relevant ILogs.  Events
> (status objects) logged on the ILog are then distributed to the relevant
> listeners.  You can register a listener with a specific (group of) plugin
or
> with the platform itself (the runtime plugin).  Your listener will get
only
> events for which it is registered.  The runtime plugin's log gets all
> events.
>
> The platform has a default listener which grabs all events and writes them
> to a file (<platform>/.metadata/.log).  There is also a command line
option
> (-consolelog) which installs a listener that writes the events to
> System.out.  I believe that the upcoming PDE tools will have a log console
> window.
>
> Jeff
>
> <jamsden@xxxxxxxxxx> wrote in message news:9akkfd$glm$1@xxxxxxxxxxxxxxxx
> > What are the guidelines for handling exceptions in UI plug-ins? Should
> > they
> > post an ErrorDialog and write to the Log? I see Log, the signle
> > implementation
> > of ILog is internal. How does one get the Log? Is there any other
> > framework support for logging errors?
>
>