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.
Currently there are two ways how to obtain error manager: 1. call TopManager.getDefault ().getErrorManager () or 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.
Yes, this would be very helpful for test writers.
Apply my patch to ErrorManager in actions_api branch (1.10.24) cvs upd -j actions_api ErrorManager.java
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).
Docs ought to be updated as well... I still plan to do that when I get a chance.
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 ex.printStackTrace() one time :-)
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).
Done: ErrorManager rev. 1.12, documentation (on the web site) updated, basic test written. Ethan: 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 (ttran@netbeans.org) to assign somebody to work on it.
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? :-)
Changed openide and core to use the new method.
Also I will deprecate TopManager.getErrorManager and TopManager.notifyException as being redundant, and make TM.gEM non-abstract (delegate to EM.gD).
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)
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.
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]
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.
Deprecations: committed * Up-To-Date 1.41 openide/src/org/openide/TopManager.java
The ErrorManager is now really found using lookup: committed * Up-To-Date 1.131 core/src/org/netbeans/core/NbTopManager.java committed * Up-To-Date 1.19 core/src/org/netbeans/core/lookup/TMLookup.java committed * Up-To-Date 1.103 core/src/org/netbeans/core/resources/mf-layer.xml 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.
Created attachment 4437 [details] Demo module JAR
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 = it.next (); if (o.getClass () == BugsubmiterErrorManager.class)) { continue; } find = (ErrorManager)o; break; } and now delegate what is needed to the found ErrorManager...
#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.
This issue had *1 votes* before move to platform component