Regis wrote: > Jim Yu wrote: >> 2008/12/5 Regis <[EMAIL PROTECTED]> >>> Kevin Zhou wrote: >>> >>>> The FileNotFoundException is being thrown by the constructor of >>>> FileOutputStream when that constructor is attempting to open File f for >>>> writing and it doesn't have permission to do so. >>>> >>>> To open f the FileOutputStream class is calling >>>> org.apache.harmony.luni.platform.OSFileSystem.open(). The >>>> o.a.h.l.p.OSFileSystem.open() method invokes a native openImpl() >>>> method. >>>> The >>>> native method can fail for several reasons. The problem lies in the >>>> fact >>>> that the reason behind the failure of the native method isn't being >>>> propagated back to the FileOutputStream which is creating the >>>> FileNotFoundException upon failure. >>>> >>> Yes, the native code just return -1 to indicate an error occurred, >>> while in >>> hyfile.c::hyfile_open, error messages are set by >>> portLibrary->error_set_last_error, but the caller never use them. So I >>> suggest to add a method in OSFileSystem.c to retrieve the error >>> messages. >>> The java could get the failure reasons when the native return -1, and >>> add >>> them to the exception message. >> >> >> Agree to add a method for retrieving the error message from Port Library >> which can be invoked by Java code. Maybe there are more cases which >> have the >> similar requirements of retrieving the error message. > > Yes, we could supply the utility function first, and then use it when > needed. If no one object I would like to add this function.
How about raising the exception (with the right message) in the openImpl native code rather than just returning -1 and crossing the JNI-boundary again to find the reason? There are other cases (i.e. other than FileNotFound) that you might want to distinguish through IOExceptions too. Regards, Tim
