Re: [cdt-dev] Error reporting with code recommenders

[Alex Blewitt <alex.blewitt@xxxxxxxxx>]

In this case the name of the tool is in the subject so they aren't getting grouped/ignored together. As a result we need to ignore each one by name. 

Sent from my iPhat 6

On 20 Feb 2015, at 20:43, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:

- please forward to cdt-dev if relevant -

What is interesting is that we are discussing improving the user experience using a clear message in a dialog
*because* we were made aware that this error was happening to users.  So maybe getting reports for such
errors does provide some useful information...  But we probably don't want to be bombarded by them.
What does the Error reporting tool do if this error keeps happening to many users?

Personally, I think this is a valuable discussion to have.

Regarding what the error reporter can do or how it deals with this just a few short comments:

1. the reporter remembers what was send before, i.e., (exactly) same errors are skipped and the user won’t see the popup for the same error twice.

2. Problems can be marked as "log messages" in the web ui. We (plan to) generate a server-side managed ignore list based on these selections. This list will be downloaded by clients from time to time and used to complete the client’s ignore list.

What else do you think is needed?

Best,

Marcel

On 20 Feb 2015, at 21:29, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:

It sounds more user-friendly to have a descriptive dialog explaining what the user can do to resolve the issue.
We've added that when trying and failing to run GDB for debug.
Could you open an enhancement bug?

If we use a dialog, it doesn't really matter if we also log it in the Eclipse log except for the Error reporting tool;
in fact, in some cases where a user sends the log to us, it may prove useful to see such errors, so I would suggest
keeping them but silencing them in the Error reporting tool

What is interesting is that we are discussing improving the user experience using a clear message in a dialog
*because* we were made aware that this error was happening to users.  So maybe getting reports for such
errors does provide some useful information...  But we probably don't want to be bombarded by them.
What does the Error reporting tool do if this error keeps happening to many users?

Thanks for looking into this by the way.

---

From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Alex Blewitt [alex.blewitt@xxxxxxxxx]
Sent: February 20, 2015 11:22 AM
To: Marcel Bruch; CDT General developers list.
Subject: [cdt-dev] Error reporting with code recommenders

CDT developers, 

I’ve been looking through a few reports that are being reported with the new tool that Marcel has helped put together. It sends reports from the error log that Eclipse looks after.

Some of the reports are due to missing program files (like make, cp etc.) such as the following:

https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4f32bbee810030da0ab01/details

java.io.IOException: Cannot run program "g++": Unknown reason
at	org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:349)
at	org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:91)
at	org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:91)
at	org.eclipse.cdt.core.CommandLauncher.execute(CommandLauncher.java:194)
at	org.eclipse.cdt.internal.core.BuildRunnerHelper.build(BuildRunnerHelper.java:263)

These aren’t real errors as such, so I’d like to find a way of filtering them out. However, I have a couple of thoughts:

1. Should these errors be reported in the Eclipse log at all? Would it be better to display a different dialog to the user and catch the exception, rather than letting the Eclipse platform handle it?

2. Is there a better message that could be reported for the user, such as “Please install tool g++” or “Configure the path to g++ from the following preference page”?

3. Should we be ignoring IOException: Cannot run program “.*”: Unknown reason, and keeping the behaviour the same? (This is mostly to Marcel, who knows how the ignoring errors work)

Alex

-- 

Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt

Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940