Community
Participate
Working Groups
ProvUI provides methods for handleException, reportStatus. These are good for encapsulating workarounds for the platform status handlers and such, but currently the methods automatically decide when a dialog vs. logging is appropriate based on the severity. Clients should be able to override this. For example, when a viewer element encounters certain kinds of errors, it should just log the problem vs. interrupt the user, depending on the nature of the exception.
An alternate way to view this issue is: should errors always interrupt? And things that don't warrant interrupting should instead be warnings? For an example, see bug #212708, where the UI interrupts the user on an error during phase collect because the user was disconnected. Should the engine have reported a warning or info status rather than error? Or is it indeed contextual, where a failure in the update checker wouldn't be as bad as a disconnected failure on a user-initiated operation?
My general experience is that it comes down to context. I typically think of three levels of interaction/intrusiveness: - Daemon-type processes that generally operate outside user awareness. I.e., things that happen automatically or "for free". Examples would be auto-refresh, auto-build, auto CVS sync, automatic update checks, etc. With these processes you almost never want to intrude on the user, at most logging or even swallowing certain well understood exceptions. - Things initiated by the user, but then punted into the background (user jobs). These things want to have a way to get the user's attention when there are interesting results or problems, but you generally don't want a modal dialog in your face - Entirely user-driven processes, such as wizards, refactorings, long-running foreground operations that require user interaction. At your level in the UI, you may know which of these groups you fall into and know how to report problems. Any API that can be called programmatically can't determine the context and therefore doesn't know the appropriate status handling behaviour. At best they can clearly specify via severities and status codes what happened, and leave it up to the client to react accordingly.
For M6 I'm going to change the ProvUI.reportStatus and handleException methods to take a parameter along the lines of StatusManager.LOG, etc... While doing this I'm also going to provide more specific error text where it makes sense rather than always relying on the exception message as the top level message.
Fixed in HEAD. All errors are logged at a minimum. Depending on the context, I may do more. - StatusManager.BLOCK (blocking dialog) is for serious errors that directly result from a user action. Cases where the user has pushed a button or menu item expecting to see a dialog, and the dialog can't be shown for whatever reason. - StatusManager.SHOW (non-blocking dialog) is used for most errors that result from user operations, including those that allowed the user to continue working while the operation occurs in the background. - StatusManager.LOG is used when a non-user background operation has an error. Meaning, the user didn't directly request the operation to occur. This includes background updating, any background process failures in trying to populate viewers, etc. Also, in cases where it would be appropriate to use StatusManager.SHOW, but there is a local mechanism for reporting an error (in the status area of a wizard, or in the viewer content itself), the error is shown locally and only logged.
