Bug 183824 - [api][breaking] IRemoteFileSubSystem should forward exceptions rather than showing dialogs
Summary: [api][breaking] IRemoteFileSubSystem should forward exceptions rather than sh...
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: 2.0   Edit
Assignee: Martin Oberhuber CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on: 187218
Blocks: 170923 170926 182221
  Show dependency tree
 
Reported: 2007-04-24 12:49 EDT by Martin Oberhuber CLA
Modified: 2008-08-13 13:18 EDT (History)
4 users (show)

See Also:


Attachments
Refactoring script with method signature changes in IRemoteFileSubSystem (28.95 KB, text/plain)
2007-05-10 12:12 EDT, Martin Oberhuber CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-04-24 12:49:59 EDT
+++ This bug was initially created as a clone of Bug #182221 +++

Some methods in IRemoteFileSubSystem throw exceptions in case an error occurs (e.g. listFilesAndFolders(), connect() which is inherited from ISubSystem, ...) while others try to handle exceptions themselves by showing a SystemMessageDialog (e.g. download()).

Showing a dialog in the Subsystem implementation is problematic, because

1. It makes mass file copies impossible because they would handle exception
   for every file rather than once in a MultiStatus
2. It requires UI but Subsystem code should be non-UI
3. Extenders cannot deal with exceptions in a way they would prefer - this
   is particularly problematic for EFS
4. It makes the code inconsistent and blown up, e.g. bug 182221

As a general guideline, non-UI-code should throw exceptions, and UI code should handle them. Subsystems should be considered non-UI code. Work items:

* Remove SystemMessageDialog from all IRemoteFileSubsystem implementations; 
  similar for Processes if needed
* Change Method signature of IRemoteFileSubsystem to throw 
  SystemMessageException wherever needed
* Adapt all callers to deal with the SystemMessageException themselves.
Comment 1 Martin Oberhuber CLA 2007-04-25 16:48:05 EDT
I'll attempt fixing this for M7.
Comment 2 Martin Oberhuber CLA 2007-05-10 12:12:17 EDT
Created attachment 66707 [details]
Refactoring script with method signature changes in IRemoteFileSubSystem
Comment 3 Martin Oberhuber CLA 2007-05-10 12:12:39 EDT
Work completed, checkin comment: 
[183824][api] Forward SystemMessageException from IRemoteFileSubsystem rather than handling it

Attached refactoring script has a record of the method 
signatures changed, though applying this script to a local
workspace will only change signatures in subclasses of 
IRemoteFileSubSystem so it will not be beneficial for many
extenders.

The following methods in IRemoteFileSubSystem were changed
to throw SystemMessageException instead of other exceptions
they threw before; implementation in FileServiceSubsystem
was changed to forward exceptions rather than showing a 
dialog.

Client code was updated to show the appropriate message
dialogs. It might be that I missed some occurrences, so
some exceptions during remote file operations might now
be swallowed silently rather than showing a dialog. 
It's expected that these will be found during testing 
later, but the API is certainly improved now.

Changed methods in IRemoteFileSubSystem:
copy()
copyBatch()
createFile()
createFolder()
createFolders()
delete()
deleteBatch()
download()
move()
rename()
setLastModified()
setReadOnly()
upload()
Comment 4 Martin Oberhuber CLA 2008-08-13 13:18:26 EDT
[target cleanup] 2.0 M7 was the original target milestone for this bug