[ https://jira.jboss.org/browse/SHRINKWRAP-204?page=com.atlassian.jira.plug... ] Andrew Lee Rubinger reopened SHRINKWRAP-204: -------------------------------------------- Would like to discuss this one a bit before we close it off. What's the motivation for throwing IOException instead of returning null? Can we instead consider widening the defined scope of IllegalArchivePathException and use that? This doesn't seem like a real I/O problem to me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SHRINKWRAP-204?page=com.atlassian.jira.plug... ] Andrew Lee Rubinger commented on SHRINKWRAP-204: ------------------------------------------------ I don't think as a general rule, we should be pointing to the java.io relying upon FileNotFoundException for flow control as an example of "what to do". The difference is this: File operations are not isolated to a particular O/S process. This means that you cannot ever, in an atomic operation, check File.exists() and be ensured that the File will still be there when you go to open the stream. FileNotFoundException is therefore required handling for stuff like URL.openStream. And I've never really felt it should extend IOException (hence force the user to handle it / be checked). The current patch here now throws IOException, which doesn't really say anything to the type system about what's going on. At a minimum, I think we should be throwing a subclass of IOException, but really I think IllegalArchivePathException makes more sense here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SHRINKWRAP-204?page=com.atlassian.jira.plug... ] Aslak Knutsen edited comment on SHRINKWRAP-204 at 7/11/10 2:22 PM: ------------------------------------------------------------------- Users of the FileSystem API are expected to handle the checked exception IOExceptions if it should occur. By API. I don't see why our implementation should change those rules by throwing a RuntimeException outside the expected type tree. As long as we're implementing a defined API, we should follow that API whether we feel it to be the ultimate correct way or not. I agree, we can throw a subclass instead of the raw IOException. e.g. AssetNotFoundException was (Author: aslak): Users of the FileSystem API are expected to handle the checked exception IOExceptions if it should occur. By API. I don't see why our implementation should change those rules by throwing a RuntimeException outside the expected type tree. As long as we're implementing a defined API, we should follow that API whether we feel it to be the ultimate correct way or not. I agree, we can throw a subclass instead of the raw IOException. e.g. AssetNoFoundException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SHRINKWRAP-204?page=com.atlassian.jira.plug... ] Aslak Knutsen commented on SHRINKWRAP-204: ------------------------------------------ One should 'always expect' a RuntimeException, but that's not the point. As you your self said: File systems are none atomic, so exceptions on operations like openStream are used and expected by users and should be handled. That being problems opening the stream or reading the stream, it is all expressed via exceptions. The API use IOExceptions for this, so why should we throw something unexpected from our implementation ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SHRINKWRAP-204?page=com.atlassian.jira.plug... ] Andrew Lee Rubinger updated SHRINKWRAP-204: ------------------------------------------- Fix Version/s: (was: 1.0.0-alpha-11) Unscheduling from 1.0.0-alpha-11 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira