This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 16854 - Enhance the API of ErrorManager
Summary: Enhance the API of ErrorManager
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: issues@platform
Depends on:
Blocks: 16853 17747 19443
  Show dependency tree
Reported: 2001-10-23 13:29 UTC by Jaroslav Tulach
Modified: 2008-12-23 14:33 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Demo module JAR (16.58 KB, application/octet-stream)
2002-01-26 14:40 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2001-10-23 13:29:35 UTC
Currently there are two ways how to obtain error manager:

1. call TopManager.getDefault ().getErrorManager ()
2. Lookup.getDefault ().lookup (ErrorManager.class)

the problem of the first one is that it cannot be used in standalone libraries
like filesystems (they cannot depend on TopManager)

but the second is also not perfrect because it can return null

Please add ErrorManger.getDefault () method that will be implemented via the
lookup, but in case the lookup returns null a default (simple) implementation
will be provided.

That way all users of the API will only need to call ErrorManager.getDefault
().notify (...) and will not need to care about the rest.
Comment 1 Jesse Glick 2001-11-06 14:54:00 UTC
Yes, this would be very helpful for test writers.
Comment 2 Jaroslav Tulach 2001-11-27 09:04:01 UTC
Apply my patch to ErrorManager in actions_api branch (1.10.24)

cvs upd -j actions_api

Comment 3 Jesse Glick 2001-12-18 00:46:26 UTC
Yarda suggests possibility on nbdev: EM.gD() could actually delegate
to all available impls. Would be useful in the case of the bug
submitter module; perhaps harmful in case of really alternative impls
(like NbErrorManager vs. hypothetical JDK 1.4-based EM).
Comment 4 Jesse Glick 2002-01-16 14:21:56 UTC
Docs ought to be updated as well... I still plan to do that when I get
a chance.
Comment 5 Petr Nejedly 2002-01-16 14:56:15 UTC
And don't forget to update o.o.util.Utilities.errMan and all its
usages in that package. We may even get rid of all
one time :-)
Comment 6 Ethan Rider 2002-01-16 22:56:59 UTC
It would be excellent if there were an IDE Setting to specify which
(even if only one) of the ErrorManagers to use (rather than requiring
a System property setting). 

Additionally it should be considered whether or not this problem comes
from the fact that there are really different types of things being
discussed: ErrorManagers | ErrorConsumers (those that handle/annotate
error data | those that use this output for some other purpose)

Perhaps it is really that the API should be extended to allow
registration of arbitrary error consumers that work concurrently
(basically just listeners). 

Comment 7 Jaroslav Tulach 2002-01-17 12:12:27 UTC
Done: ErrorManager rev. 1.12, documentation (on the web site) updated,
basic test written.

1. you can register your error manager using lookup, no need for
system property
2. if you want to modify API to allow more ErrorManagers to be
delegated to, create new bug (it might block issue 19443) and try to
convince Trung ( to assign somebody to work on it.
Comment 8 Jesse Glick 2002-01-17 13:16:10 UTC
To pnejedly: yes someone should do a sweep over openide (not just
org.openide.util, elsewhere too) replacing complex code w/ EM.gD().
Also core module tests can use this I think. Are you volunteering? :-)
Comment 9 Jaroslav Tulach 2002-01-17 16:14:46 UTC
Changed openide and core to use the new method.
Comment 10 Jesse Glick 2002-01-17 17:31:06 UTC
Also I will deprecate TopManager.getErrorManager and
TopManager.notifyException as being redundant, and make TM.gEM
non-abstract (delegate to EM.gD).
Comment 11 Petr Nejedly 2002-01-18 10:56:32 UTC
OK, I could wo a sweep in my spare time :-)
But when doing so, I'd like to clean it a bit more.

1. Is it OK to replace all copyAnnotation with annotate?
(they differ only in severity - UNKNOWN vs EXCEPTION)

2. Is it OK to replace all TM.notifyException() with em.notify()?
  (There is InvocationTE unfolding in TM)

Comment 12 Jesse Glick 2002-01-18 12:57:23 UTC
I am deleting the hack for InvocationTargetException in NbTM, it is
wrong (NbEM already handles this correctly), and deprecating both
methods as I said, so yes go ahead and replace these if you want.
copyAnnotation() is probably useless, I am not positive.
Comment 13 Jaroslav Tulach 2002-01-18 15:36:32 UTC
The correct behaviour for severity is probably to extract it from the
previous exception (if there is any) and if not assign UNKNOWN => if
there is not assignment at all in the annotations EXCEPTION is used by
NbErrorManager. [please verify I am right]
Comment 14 Jesse Glick 2002-01-18 16:04:18 UTC
That severity algorithm sounds reasonable, I suppose. However last I
checked severity does not really work anyway unless you notify with
it, so I'm not sure this would have any effect. I don't know what the
intended behavior of severity really is.
Comment 15 Jesse Glick 2002-01-20 16:06:14 UTC

committed   * Up-To-Date  1.41       
Comment 16 Jesse Glick 2002-01-26 14:40:12 UTC
The ErrorManager is now really found using lookup:

committed   * Up-To-Date  1.131      
committed   * Up-To-Date  1.19       
committed   * Up-To-Date  1.103      

This means you can register a different one using layer, just by
putting it in front of the core's one.

Note however that an ErrorManager is needed early in IDE startup. So
NbErrorManager is still used until layers are merged and lookup is
ready. This is unavoidable, I think.

Setting org.openide.ErrorManager still works, assuming the impl is on
the classpath, but is deprecated. It does however replace
NbErrorManager completely, even during startup.

Will attach a module demonstrating a custom error manager. If you
remove the manifest and place the JAR on the classpath and use
-J-Dorg.openide.ErrorManager=<classname> you can see the other style
in action.

I think the question of delegation is still open. There probably does
need to be a separate "error consumer" or listener, which bugsubmitter
could register one of without replacing the normal error manager.
Comment 17 Jesse Glick 2002-01-26 14:40:47 UTC
Created attachment 4437 [details]
Demo module JAR
Comment 18 Jaroslav Tulach 2002-01-28 09:30:31 UTC
1. The error manager could be registered soon enough if we implement
issue 14722. 

2. The bugsubmiter can do following trick:

Iterator it = Lookup.getDefault ().lookup (new Lookup.Template
(ErrorManager.class)).allInstances ().iterator ();
ErrorManager find = null;
while (it.hasNext ()) {
	Object o = ();
	if (o.getClass () == BugsubmiterErrorManager.class)) {
	find = (ErrorManager)o;

and now delegate what is needed to the found ErrorManager...

Comment 19 Jesse Glick 2002-01-28 14:21:14 UTC
#1 - this won't help much. It will make registration a bit earlier,
but still not in time to prevent the first EM from being NbErrorManager.

#2 - this is OK, if a little clumsy.
Comment 20 Quality Engineering 2008-12-23 14:33:47 UTC
This issue had *1 votes* before move to platform component