Community
Participate
Working Groups
Many code call the Core resources APIs in read only mode. Such code must be written to appropriately handle exception caused by some bugs, and exceptions caused by some events performed by the user. For instance, if code is performing read operation on a project, and the user closes the project in the workspace, this code must be able to handle gracefully this exception, and not generate a error, while other kind of unexpected exceptions should cause error logs to be generated. Right now, core resources generates mostly CoreExceptions (and ResourceExceptions, which isn't public). The Project.checkAccessible() and Resource.checkAccessible() is one example of such code that throws ResourceExceptions (seen as CoreException from the client) from different API code path, and that client code cannot reliably determine which is the cause of. The core resources APIs should throw public specialized Exceptions, starting with ProjectNotAccessible exception (inheriting from ResourceException) in the case of PRoject.checkAccessible() and Resource.checkAccessible().
John or Szymon, can you comment on this feature request?
I'm not a fan of having lots of specific exception classes. They bloat the API and it is difficult for people to learn all the classes and what they do. In the resources API we instead use IResourceStatus which lists all of the possible status codes for errors and warnings. Maybe what you are looking for is something like IResourceStatus.PROJECT_NOT_OPEN? Note that "not accessible" in resource API has two possible causes: 1) resource does not exist. 2) Resource belongs to project that is not open. We don't seem to currently distinguish those two cases in Resource#checkAccessible, but we could if you think it helps.
I checked how IResourceStatus is used in core.resources API and we have good examples like: IProject#build(int kind, String builderName, Map<String,String> args, IProgressMonitor monitor) throws CoreException where it is said: *@exception CoreException if the build fails. *The status contained in the exception may be a generic {@link IResourceStatus#BUILD_FAILED} *code, but it could also be any other status code; it might *also be a {@link MultiStatus}. and bad examples, like: IFile#getContentDescription() throws CoreException or IFile#create(InputStream source, boolean force, IProgressMonitor monitor) which mention reasons for CoreException, but do not refer IResourceStatus. However then client code in UI, for instance IDE#getContentType(IFile file) relies on these codes. So as John said we could use IReosurceStatus, but it should be clear in the javadoc what codes may be returned. For instance for IProject#getDescription we should say: /** * Returns the description for this project. * The returned value is a copy and cannot be used to modify * this project. The returned value is suitable for use in creating, * copying and moving other projects. * * @return the description for this project * @exception CoreException if this method fails. Reasons include: * <ul> * <li> This project does not exist, the code is {@link IResourceStatus#PROJECT_NOT_OPEN}.</li> * <li> This project is not open, the code is {@link IResourceStatus#RESOURCE_NOT_FOUND}.</li> * </ul> * @see #create(IProgressMonitor) * @see #create(IProjectDescription, IProgressMonitor) * @see IResource#copy(IProjectDescription, int, IProgressMonitor) * @see #move(IProjectDescription, boolean, IProgressMonitor) * @see IResourceStatus#PROJECT_NOT_OPEN * @see IResourceStatus#RESOURCE_NOT_FOUND */ What do you think?
Yes that looks good. Not sure the @see is really needed for all the codes if we already have the @link just above.
Just poking as it seems this issue has stalled. Would be nice if this was resolved so we could avoid a lot of exceptions that are now showing up in the .log file
Serge, any plans to continue working on this?
Removing milestone. If someone starts to work on this they should assign a milestone, but currently nobody is looking at it.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
