Community
Participate
Working Groups
When an end user encounters a problem with Eclipse, it is important for support teams to be able to diagnose the root cause of the failure, and identify the failing plug-in. Eclipse should have enhanced error reporting tools that make it easy for end users to report problems. Tools should be available at all times, so that knowledgeable users can diagnose unexpected behavior such as slow-downs or exceptional memory use. Error handling is done in a variety of ways within the platform which are not extensible to RCP applications. An improved story would allow for the inclusion of application defined error support (such as a link to a support centre for the product) and remote monitoring/inspection of system health and would tie the current error reporting story together into a solution with a more consistent look and fewer error reporting paths for developers.
*** Bug 106193 has been marked as a duplicate of this bug. ***
Assigning to Tod for now.
Created attachment 48071 [details] List of possible themes and associated bugs for 3.3 Attaching doc here although it contains more than just ErrorHandling... Do we want a bugzilla for each 'theme' and we will decide which theme we tackle first ? Or should we keep the full bucket here and open a bugzilla for each 'issue' we want to solve ?
(In reply to comment #3) > Attaching doc here although it contains more than just ErrorHandling... > Do we want a bugzilla for each 'theme' and we will decide which theme we tackle > first ? Or should we keep the full bucket here and open a bugzilla for each > 'issue' we want to solve ? I would suggest the second approach because it allows interested parties to watch this bug and be notified whenever one of the "depends on" bugs changes state.
+1 for Boris's idea. We usually keep the main bug for a place to start from and add a dependency for each issue - if not it is too easy to miss something.
*** Bug 115193 has been marked as a duplicate of this bug. ***
An FYI for those following serviceability improvements in the platform, I have just addressed bug 38136. This adds a new marker attribute that will make is easier for support people to track down who a marker was created by.
As a plugin developer, it would be nice to specify to the platform to send the bugs that occur in my plugin to me. For instance, if a stack trace is involved in a problem which a user reports then the platform should be smart enough to figure out it is my plugin that caused the error and notify me (as opposed to the Eclipse team). This may involve plugin creators specifying a repository to send errors to in the plugin manifest. To take it a step farther, it would be cool if the platform would just insert the error straight into my bugzilla site.
Mylar's task management support allows a new bug report to be created from any event in the Error Log view, and for the contents of that event to populate the bug report. If the event has a Java exception stack trace in it, it will also run a search against the repository to find any potential duplicates and allow the user to comment instead of creating a new bug report. Refer to the "Report Bugs" and "Duplicate Detection" items her for more info: http://eclipse.org/mylar/doc/new.php This works for Bugzilla and Trac repositories. Also, note that we have support for automatically adding repositories, e.g. adding the bugs.eclipse.org repository for Eclipse users. However, we have not enabled this in the UI because in our experience it's best to have a user explicitly add a repository and validate their credentials sine most issue trackers are not configured to allow anonymous bug reports to be submitted. What we haven't yet done is the association between the plug-in originating the error and the task repository and component that the bug should be filed under (this is bug 150278). Currently we think that the best way to do this will be via extension point not by a manifest declaration, but we're open to suggestions because it would be nice if plug-ins could do this without coupling to a Mylar extension point. We have also been holding off on making uncaught errors automatically trigger this processes while we figure out how to build on the serviceability effort described here. What's the best way for us to proceed? I figure that once bug 160303 is resolved we'll try to move our error handling facility to that and post experiences?
Is there a pointer for how to extend the new error handling facility? I'd like Mylar to try it and ensure that we can use it for prompting the user to submit a bug. If you point us at which class or classes to use/extend that will be sufficient, we'll glean the rest from the source.
Hello Mik, I could give you a sample already made, but... do you mind pretending you know nothing about eclispe (yeah I know it will be hard) and check the class org.eclipse.ui.statushandlers.StatusManager ? I want to know if the name of the classes and the javadoc are sufficient enough so one knows how to use it... are you game to try that ?
I'd be very happy to do that. Ever since an old mentor of mine taught me to "Use the source, Luke" I have relied almost exclusively on code and naming conventions to understand Eclipse :) The quality of the type and method naming in Platform is so good that it's a rare event for me to unfold the Javadocs. Next week I'll try to extend the statushandlers stuff, with a newcommers perspective, and report back.
(In reply to comment #12) > Next week I'll try to extend the statushandlers stuff, with a newcommers perspective, and report back. Fyi, we weren't able to squeeze this into last Friday's Mylar 2.0M2 release, but plan on trying the move to statushandlers this week.
Mik, Seems like you manage to use the API :) Great, I added a rough draft of the usage of StatusManager, please feel free to criticize... http://wiki.eclipse.org/index.php/Status_Handling_Best_Practices
Marking as FIXED as we are now heading into release candidates.
Marking VERIFIED
