Do not show error popup when build fails

laeubi commented 1 year ago

Recently I started to get some disturbing error popups because of the Checkstyle not working well with Java 17(?).

Even though the plugin needs to get fixed, the error popup is very disturbing to the user (and actually not helpful at all), I can think of the following, less disturbing actions:

just write the problem to the error log (as it is already done)
add an error marker to the project that for example has a quick-fix to remove the faulty builder from the project.

For reference here is the stack-trace I could extract from the error log, and the popup

grafik

java.lang.reflect.InaccessibleObjectException: Unable to make field private static volatile java.net.Authenticator java.net.Authenticator.theAuthenticator accessible: module java.base does not "opens java.net" to unnamed module @41cbb14f
    at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
    at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
    at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
    at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
    at net.sf.eclipsecs.core.config.configtypes.RemoteConfigurationType$RemoteConfigAuthenticator.getDefault(RemoteConfigurationType.java:376)
    at net.sf.eclipsecs.core.config.configtypes.RemoteConfigurationType.getCheckstyleConfiguration(RemoteConfigurationType.java:99)
    at net.sf.eclipsecs.core.config.CheckConfiguration.getCheckstyleConfiguration(CheckConfiguration.java:161)
    at net.sf.eclipsecs.core.builder.CheckerFactory.getCacheKey(CheckerFactory.java:157)
    at net.sf.eclipsecs.core.builder.CheckerFactory.createChecker(CheckerFactory.java:99)
    at net.sf.eclipsecs.core.builder.Auditor.runAudit(Auditor.java:139)
    at net.sf.eclipsecs.core.builder.CheckstyleBuilder.handleBuildSelection(CheckstyleBuilder.java:307)
    at net.sf.eclipsecs.core.builder.CheckstyleBuilder.build(CheckstyleBuilder.java:173)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1020)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:247)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:392)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:395)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:506)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:454)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:536)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:161)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:255)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

merks commented 1 year ago

When something goes very wrong, just logging the problem quietly might well leave the user wondering why things don't actually work properly yet having no clue why that might be the case. How about a checkbox to not show the dialog again so that we leave this choice up to the user?

laeubi commented 1 year ago

The problem is that this just popup into the way when working on a project, it disturbs my current workflow and it gives zero information what to do or how to solve the problem. Even worse, dismiss the dialog might open it again a short time later.

So what should the user do (instead of dismiss the dialog) here? Even if it is fatal and something is not working, I as a user would start investigate whats going on for this particular thing e.g.:

check configuration
take a look at the error log
complain at the projects support-channels
....

almost never I will be satisfied by dismissing a dialog that comes in my way when writing code...

mickaelistria commented 1 year ago

How about a checkbox to not show the dialog again so that we leave this choice up to the user?

Even that is a bit tricky: imagine there is a checkstyle error that cause the popup to show, it may not be important as it happens late after other actual "build" (ie creating artifacts) steps are run, so user checks "Do not show again" and decide to not care. Later, a build error happens in the Maven or JDT nature, so breaking production of artifacts that are used by other projects, what should happen? Should the dialog remain hidden as requested by user, or should it be shown because it's a new error? My take is for the later, but it becomes complex to implement. For this particular case, I don't believe the popup per se is to blame, but it's content and lack of assistance:

Is it possible to get the stack trace from the "Details" button?
Should the popup mention that user may be able to try disabling this particular build step?
Could we get more details about the build, reporting the successful builder executions and the one(s) that failed?
...

I believe if the popup is improved to become more helpful, it becomes less annoying: it's not noise anymore, but an assistance to better project configuration.

iloveeclipse commented 1 year ago

First of all: how about fixing the broken software? With error free software the errors will be not shown.

Note: markers have to be removed, but they are managed by builders created the marker - in this case which builder is supposed to remove "I've failed to build" marker? The faulty one for sure not. The good one neither.

One can investigate if "tray notification" could be used instead of dialogs for reporting unexpected errors - it can be configured to disappear after some time, and it could stay in the status line (like Oomph wizard progress button).

laeubi commented 1 year ago

First of all: how about fixing the broken software?

As a user I want to finish my task, I don't want to fix other software before. This is just something users will blame on Eclipse-IDE even though we can tell them to blame it on the others project user will get frustrated.

I believe if the popup is improved to become more helpful, it becomes less annoying: it's not noise anymore, but an assistance to better project configuration.

The problem is that the error is most likely unexpected (otherwise it would have been already handled properly) so there actually nothing useful one can do.

One can investigate if "tray notification" could be used instead of dialogs for reporting unexpected errors

Even that can be too noisy I think, as the user can do nothing about this but is just disturbed in its workflow (whether or not it makes sense anymore). See for example: https://learn.microsoft.com/en-us/windows/win32/uxguide/winenv-notification (emphasis by me)

The notification area provides notifications and status. Well-designed programs use the notification area appropriately, without being annoying or distracting.

Also https://learn.microsoft.com/en-us/windows/win32/uxguide/winenv-notification#is-this-the-right-user-interface

Is the status useful and relevant? That is, are users likely to monitor the icon and change their behavior as a result of this information? If not, either don't display the status, or put it in a log file.

mickaelistria commented 1 year ago

The problem is that the error is most likely unexpected (otherwise it would have been already handled properly) so there actually nothing useful one can do.

If we can show the stacktrace to user in the details with a message "Consider fixing or removing the Project Builder that has caused this error", then it tells something useful one can do.

I still believe a popup is important here, because we just don't want the user to start ignoring those errors. For Checkstyle, it's not too bad, but same error on some other builder that runs first can cause the whole workspace to be unusable, it's serious enough to deserve being explicitly annoying users so they try to resolve it.

iloveeclipse commented 1 year ago

Whatever will be outcome here: buggy software must show user that it can't work. Just reporting something in the log is not sufficient, because most of the users not even aware there is an error log.

laeubi commented 1 year ago

If the user do not notice anything is wrong, why bug them? If the user notice "feature x is not working" he will start investigate why (in whatever way) and probably ask the provider of X to fix the problem, this is nothing the user can fix here.

mickaelistria commented 1 year ago

If the user do not notice anything is wrong, why bug them?

Because something is actually wrong and for this reason some things won't work as designed by tools developers. User may not even realize that. They must be warned about the reason and the consequences.

If the user notice "feature x is not working" he will start investigate why (in whatever way)

That's not generally true. Many people do work with crippled applications because of some bugs or bad configuration they're not even aware of and just assume that "X sucks" because they cannot access all the powers of X; while the popup tells "X has an issue, it's important to remediate it if you want full power".

laeubi commented 1 year ago

Because something is actually wrong and for this reason some things won't work as designed by tools developers. User may not even realize that. They must be warned about the reason and the consequences.

Why must they be warned? Will this delete their hardisk? I don't think so, this only annoy the users as it annoy them to dismiss cookie dialogs or security warnings it is not useful at all and do not help them as there are only two cases:

for the current action it doesn't matter
for the current action it is relevant and then I'll notice that feature X is not working, but I don't care that BuilderWhatEverIHaveNoClueAbout has thrown an StupidExcpetionIHaveNoIdeaWhatItMeans.

One should not expect that users are Domain-Experts of all their tools and the implementation details of those... So for anyone not familiar with Eclipse development this is simply irrelevant information.

That's not generally true. Many people do work with crippled applications because of some bugs or bad configuration they're not even aware of and just assume that "X sucks" because they cannot access all the powers of X; while the popup tells "X has an issue, it's important to remediate it if you want full power".

Yes an generally they think that X sucks even more if dialogs get in their way ;-) Throwing modal dialogs at the user is clearly not what makes them aware of all the cool features of an application...

mickaelistria commented 1 year ago

Why must they be warned?

I and others already answered that. A build failure has high risk of reducing usability of the whole IDE. It's not just "feature X", it's the whole workspace that can be broken for such case. Yes, it's serious.

laeubi commented 1 year ago

And how does the popup help the user with this serious problem? I really thing this "break whole workspace" is more a hypothetical than a practical issue, I have never seen this, while I often has seen the distracting popup, in all cases the only impact was that for example check-style is not working, or m2e can not update all aspects of the project ... for sure this reduces the usability more or less, but the popup has never improved anything beside making it even less useful.

mickaelistria commented 1 year ago

And how does the popup help the user with this serious problem?

It's interrupting them and showing an error. But indeed, it could be better, and improvements towards making it better would most likely be welcome by all.

I really thing this "break whole workspace" is more a hypothetical than a practical issue, I have never seen this,

I don't have an obvious example, but the way the Build API contract is designed makes that this issue is possible and can be critical. We cannot suddenly just reduce its importance because you don't like this pop-up in a corner case of m2e... There is a much wider world using Eclipse Builders.

the popup has never improved anything beside making it even less useful.

At least you looked at the log and realized the builder was the issue. So the pop-up did help because it triggered you some actions, investigation and understanding. However, it's indeed not so comfortable, the stacktrace would better be shown in Details, with a note abut the ID or name of the faulty builder and project and some hints to avoid it (like disabling builder, closing project...). Improvements welcome!

akurtakov commented 1 year ago

One idea that is floating in my head is to propose uninstalling such plugins when they can be identified with clear message about that. That would certainly improve both IDE stability, user perception and plugin authors response time.

laeubi commented 1 year ago

. We cannot suddenly just reduce its importance because you don't like this pop-up in a corner case of m2e...

This is not specific to m2e and this builder has nothing to do with m2e, I just noticed that because checkstyle maven config triggers activation of checktype nature.

There is a much wider world using Eclipse Builders.

And that's why I think we will always have situations where outdated stuff can fail, and as such it should be handled with more care than breaking alll workflows of the user, the CheckstyleBuilder is really a bad citizen here and has annoyed me several times, but not always users have the choice...

At least you looked at the log and realized the builder was the issue.

I'm not feeling better now... ;-) The main point is that a plugin I don't really need for my current work (e.g. editing a java file) can completely break my work-flow and makes me mad about Eclipse trowing dialogs at me instead of write it to the log or adding an error marker or punish the plugin author ...

One idea that is floating in my head is to propose uninstalling such plugins when they can be identified with clear message about that.

I thin uninstall is not always an option, but disabling it (after asking the user) would be fine, I just not sure that all the UI work is something I'd like to do here for a case where just not showing an modal dialog would be (for me) enough...

vogella commented 1 year ago

I did not read the whole thread but using the non blocking notification APU would show the error without blocking the user flow. Sorry if that was discussed already

laeubi commented 1 year ago

but using the non blocking notification APU would show the error without blocking the user flow

Can you explain what API exactly you are referring to?

vogella commented 1 year ago

but using the non blocking notification APU would show the error without blocking the user flow

Can you explain what API exactly you are referring to?

See https://www.eclipse.org/eclipse/news/4.23/platform_isv.php#notification-api and JFace snippets for example usage. My "dream" with this API was to get rid of most blocking dialogs reporting something (Egit comes to mind with its success dialog for its operations). IntelliJ uses a similar non-blocking approach for error reporting.

Blocking the user is IMHO always bad UX as not informing the user about errors is also bad UX. Notification API should help with both concerns.

laeubi commented 1 year ago

@vogella I think even that is too annoying (see reference to the UX guide above) as the user can likely not change its workflow because of that.

Especially as there is already such kind of notification already: grafik

vogella commented 1 year ago

as the user can likely not change its workflow because of that.

Not sure what you mean, the notification could have buttons, etc to allow the user to trigger certain actions.

laeubi commented 1 year ago

I believe if the popup is improved to become more helpful, it becomes less annoying: it's not noise anymore, but an assistance to better project configuration.

Just a recent example for this ~useless~ "valuable" dialog that currently makes me force to kill Eclipse because every time I dismiss it it popup again:

grafik

This was reported over a half year to the JDT project but is not fixed:

https://github.com/eclipse-jdt/eclipse.jdt.core/issues/520

so from a users point of view this is the usual WTF?!?-Moment of Eclipse user experience, so should I follow the advice of @akurtakov now and uninstall JDT, is this seriously something we like to tell users of Eclipse?

One idea that is floating in my head is to propose uninstalling such plugins when they can be identified with clear message about that. That would certainly improve both IDE stability, user perception and plugin authors response time.

merks commented 1 year ago

Here's a sample from today trying to Oomph m2e:

I'm not sure if I'd so quickly figured out I need to remove -SNAPSHOT from Tycho's 4.0.0 version without that.

laeubi commented 1 year ago

I'm not sure if I'd so quickly figured out I need to remove -SNAPSHOT from Tycho's 4.0.0 version without that.

You should get an error marker directly in the pom.xml telling that the version was not found.

laeubi commented 1 year ago

Next "useful" occurrence of the dialog:

https://github.com/eclipse-pde/eclipse.pde/issues/709

so nothing I can change / fix as a user but makes it impossible to work with Eclipse due to constant error popup, minimizing the dialog bring it up again on the next error reported a few seconds later.

pcdavid commented 4 months ago

I personally get annoyed by this (or a similar one) very frequently when switching between Git branches which do not all have the same projects (Maven modules in my case).

Say I'm a branch1 with projects (Maven modules) a, b, and c, and switch to branch2 where b does not exist. The I get a popup "Refreshing workspace" has encountered a problem. Worse, my git repo is now "dirty" with automatically created .project files.

Maybe when switching branches directly from inside Eclipse things work better, but (as surprising as it may sound), sometimes one needs to also use other tools.

eclipse-platform / eclipse.platform.ui

Do not show error popup when build fails #509