Summary: | [resources] Need better error code in status returned from validateEdit | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Dirk Baeumer <dirk_baeumer> |
Component: | Resources | Assignee: | John Arthorne <john.arthorne> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | critical | ||
Priority: | P2 | CC: | jeem |
Version: | 2.1 | Keywords: | api |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Dirk Baeumer
2002-11-27 12:45:23 EST
Adding Jeem to CC for comment. Since you're in UI code, I assume you are passing in a context (Shell) to validate edit. If so, you don't need to report anything, as the spec states: "If a shell is passed in as the context, the VCM component may bring up a dialogs to query the user or report difficulties; the shell should be used to parent any such dialogs; the caller may safely assume that the reasons for failure will have been made clear to the user." If you're not in UI code, just display the given status to the user, and don't log anything. This is really a boolean operation: OK signals that the files are writable, ERROR signals they are not writable. There is no reason to log anything here. If the VCM component had some kind of internal error, it can log that itself. Then this should be at least speced in the Javadoc. And I am still convinced that the status returned should have a meaning full code. I'm not sure what cases are not covered by the doc. Are you thinking that the checkout might suceed but an ERROR status be returned for another reason? If there are only two possible outcomes ("the files are modifiable" or "the files are not modifiable"), then another status code isn't useful. |