Community
Participate
Working Groups
One issue with the error reports we receive, is, that we are not able to assess whether the logged error was actually caused by some bug in code or was just logged to inform the user. It's also not easy to assess the actually severity of an error. However, I think that many times committers writing a log statement know which purpose this log message serves and which severity an error logged there has. To enhance error reporting, I propose to add 'data map' (similar to Widget.setData(Map)) which allows to attach additional information to a status object. On AERI side, w'd check whether the map contains some values for keys like "aeri.send" , "aeri.severity", or "aeri.attach-eclipse-configuration" which could control how AERI treats that report. Any thoughts about adding such a new method to the API of IStatus?
I'm not sure I understand the request. Who/how/when will make use of this additional map. Are you looking for some plugins adding such data in the statuses when logging or when reading the statuses? If the former it would be tremendous amount of work to change many plugins if the later one has to be cautious with times as they are bound to the log time. As far as I understan it, currently, they are immutable and simply serialized in plain text file (workspace/.metadata/.log) with new ones simply appended. If log entries become mutable this would either cause the log file parts being rewriten in arbitrary places on setting "data map" or losing the original timestamp by removing the old and storing new entry (which would be unacceptable due to loss of information). It is possible that I totally misunderstood the request and thought of unrelated things :).
(In reply to Alexander Kurtakov from comment #1) > I'm not sure I understand the request. Who/how/when will make use of this > additional map. Who: Committers logging a status object using ILog#log(IStatus). When: When they want to influence how AERI or other log listeners treats a logged status How: IStatus status = new Status(IStatus.ERROR, "my-bundle", "some message", causing-exception); status.setData("aeri.ignore", true); ilog.log(status); On AERI side we'd check these values and respond accordingly: if(TRUE.equals(status.getData("aeri.ignore")){return;}; if(CONFIG.equals(status.getData("aeri.hints")){addEclipseConfigToErrorReport();}; Longer: The use cases I have in mind are as follows. At the moment the general workflow to log an error in Eclipse looks is ilog.log(new Status(IStatus.ERROR, "my-bundle", "some message", causing-exception)); However, a log message generally may serve different purposes. One may be to inform the Eclipse user about a problem by providing some additional details and helpful messages how to work around the issue. A second purpose may be to provide sufficient details for committers to triage this error later - e.g. after it was send to eclipse.org via AERI. In the former case, sending this error via AERI to eclipse.org would be a committer's waste of time. The committer writing above log statement knows at the time of writing the log statement that this error is actually just a "user-frontend error". Thus, it should never be send to eclipse.org. Thus, I need means to mark this error as "should be ignored by aeri". This could be implemented by adding some property to the status like status.setData("aeri.ignore", true); Having the ability to tag a status with additional information may allow us to reduce the number of pointless error reports on eclipse.org and frees up resources to triage real bugs. In the second case, the committer wants to make sure that this error will be sent to eclipse.org under all circumstances - maybe even if its not an error status: status.setData("aeri.ignore", false); In addition, he may know beforehand (or may learn later after the first error reports arrive) that he needs additional information to fix this issue, e.g the current Eclipse configuration, heap settings etc. He could provide that information by setting another property before logging it, like: status.setData("aeri.hints", "attach-eclipse-configuration"); With such a data map in place, AERI could check for additional information and complete the user's error report with the additional information automatically. The map does not need to be serialized, i.e., it may be treated as transient. Changes to org.eclipse.ui.internal.views.log.LogEntry and its (de)serialization are not requested. Does that make the use case clearer? FWIW, I thought about using ThreadLocals instead. But I'm not sure whether the thread that caused the issue actually logs the error.
