Community
Participate
Working Groups
I synchronize hourly with CVS in the background. Over half the time, the synchronization fails due to some timeout exception. I actually don't care about this unless I am going to view the results of the synchronize. (i.e. use the synchronize view or perspective). But, I get a dialog popped up reporting the error. This is especially annoying when working remotely without a newwork connection. The background synchronize should fail silently, but report the failure when I go to the sync view. Or, it would be sufficient just to display the timestamp of the last successful synchronize.
Yes this would be useful. I suggest that we add *yet* another property to a job such that if the job returns an error the user is not interrupted. This would be useful for the scheduled synchronizations. The user would simply go to the progress view and will see the latest scheduled sync and the result. There would be no interruptions in these cases. Could consider this a polish item?
When we have discussed not posting error dialogs from jobs earlier our assumption was that 1) error dialogs are rare but 2) important to the user. For this reason we were reluctant to not show them immediatly. This use case illustrates that this is not always the case. The progress view already provides the support to do so, i.e., it captures errors and you can pick them up when desired. The proposed fix would only require that progress infrastructure honors this property and not show the error notifier. Since the property is selectively enabled and we do not generally not show error dialogs I'm in favor of promoting this to a polish item. However, I want to get support from Mike on this.
I've looked into the changes required to support this. The changes are local and straightforward: * add a new property constant to IProgressConstants * ErrorNotificationManager passes a job and not the job name to addError() * inside addError() before opening the error dialog it needs to be checked whether the new property is set. Mike isn't available today, if Tod is OK with these changes then we should go ahead, it is a value add to the current progress infrastructure. The API addition to IProgressConstants is approved by me.
MVM and I are not crazy on adding new API and behaviour this late in the game. Erich is right - the intention of errors is that they are serious enough to throw something in the users face. What is wrong with making this a warning and using the progress region?
>What is wrong with making this a warning and using the progress region? not crystal clear how this would work given that the progress region is transient and the message can be quickly replaced. BTW, the general the API change rule is that we can still make them to address bugs, but they need PMC approval.
The final decision is by the component owner so I defer to Michael on how to proceed on this one.
Michael and I concur (AFAIK) that this is not something we want an API change for. I don't think it is a good idea anyways personally as errors are meant to be a serious thing that required user attention. Marking as WONTFIX
see comment #4 I don't want to add new API constant short-sightedly, errors are errors and should be dealt with in a common way in the UI. Jean-michel, we are willing to help you come up with a solution for your particular case if you need us.
re-opening for oportunity for TEAM to fix.
The reason I liked the additional property is that you would get the 'open error dialog' goto action by default and the user won't be interrupted. If a pull some magic in the cvs plugin and return a warning status from the background synchronize instead of an error I will change the goto action to copy the open error dialog. But this dialog won't be the same as the traditional job error dialog because ErrorNotificationDialog is internal. I will have to use the ErrorDialog instead, which isn't as nice.
Won't have time for 3.0. Moving to 3.1.
*** Bug 58611 has been marked as a duplicate of this bug. ***
*** Bug 71310 has been marked as a duplicate of this bug. ***
I am currently working on bug 76726 and part of the solution I have arrived at for handling non-user jobs that fail is the same as what Erich described in comment 3. I will try to have the fix reviewed and submitted by Tod by 3.1 M3. However, for this particular case, I have just released a change that will return an OK status but show the error in the GOTO action. The reasoning is that we still do not want to flood the job error list and the log with failed scheduled synchronizations and ther eis no way to prevent this except by returning an OK status. We keep the last job which will either have an error or will have succeeded (in which case the user probably doesn't care about previous scheduled syncs that failed).
