Bug 230919 - [api][breaking][files] IFileService.delete() should not return a boolean
Summary: [api][breaking][files] IFileService.delete() should not return a boolean
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement with 2 votes (vote)
Target Milestone: 3.0 RC2   Edit
Assignee: Radoslav Gerganov CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api
Depends on: 221211
Blocks: 233993
  Show dependency tree
 
Reported: 2008-05-07 11:55 EDT by Martin Oberhuber CLA
Modified: 2008-05-27 19:26 EDT (History)
9 users (show)

See Also:
mober.at+eclipse: pmc_approved+


Attachments
Patch for this bug (15.73 KB, patch)
2008-05-23 04:54 EDT, Radoslav Gerganov CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2008-05-07 11:55:48 EDT
+++ This bug was initially created as a clone of Bug #221211 +++

On bug 221211 comment 52, Rado said:
"I disagree that we need the boolean return. This may be an use-case for
deleteBatch but it is indeed an exceptional situation for delete(). Some client
has requested a delete operation -- it can fail for many reasons and one
particular reason is that the specified file doesn't exist, I consider that an
exceptional situation.
I suggest to add another exception (e.g. SystemFileNotFoundException) and catch
it in deleteBatch."

An exception is already prepared in SystemElmentNotFoundException.

Do all committers agree that we want this breaking API change that late in the game? Who would want to take the bug?
Comment 1 Radoslav Gerganov CLA 2008-05-09 02:51:36 EDT
I could implement the change if all committers agree to return void instead of boolean.
Comment 2 Martin Oberhuber CLA 2008-05-09 04:05:14 EDT
Ok, let's use Bugzilla Voting for deciding this. Here's some pros and cons:
 
 + making the change makes IFileService more consistent

 - we are past API Freeze already and the change is not absolutely necessary

I'm undecided (voting "0" for now). Others please comment on the bug, or set a "review" flag to + or -. All committers are requested to vote.
Comment 3 Radoslav Gerganov CLA 2008-05-23 04:54:30 EDT
Created attachment 101698 [details]
Patch for this bug

Attaching the patch for review.

SftpFileService#delete() throws RemoteFileIOException instead of SystemElementNotFoundException if the remote file doesn't exist because it expects attrs to be null in this case which never happens. I see two options here: throw SENFE where the FIXME marker is or check for SSH_FX_NO_SUCH_FILE in makeSystemMessageException(). Martin, I leave this decision for you.

I am going to commit the patch.
Comment 4 Radoslav Gerganov CLA 2008-05-23 08:26:58 EDT
Marking as FIXED, the problem with SftpFileService can be tracked with bug 233651.
Comment 5 Martin Oberhuber CLA 2008-05-23 13:32:37 EDT
Thanks for applying this, Rado. Implementation is now in sync with the Javadocs.

The one thing that I'm not 100% sure about is, whether we should really throw SystemElementNotFoundException in case the element(s) to delete are not found. I wrote some testcases, and found that Eclipse EFS IFileStore#delete() silently ignores this. What do you think?

The other thing is that in (FTPService, LocalFileService, SftpService), I'm not so happy about the //$NON-NLS-1$ after SystemElementNotFoundException, because I'm not sure whether we wouldn't want to have the String ("delete") externalized eventually.

I'd prefer not putting in the //$NON-NLS-1$ until it is decided that this String ("delete") really shouldn't ever be externalized.

I'm reopening to sort out these discussion items, although I approve the patch.
Comment 6 Martin Oberhuber CLA 2008-05-27 19:26:28 EDT
Marking fixed since I'm sure that throwing Exceptions is the right thing to do, and the $NON-NLS-1$ tags with exceptions don't really hurt.