Hi Regis, I also agree with Tim's approach. Adding a new method may also make the structure of code more explicit.
On Mon, Dec 8, 2008 at 10:54 AM, Regis <[EMAIL PROTECTED]> wrote: > Hi Tim and Alexei, > > Thanks your advices, I'll try the exception approach. > > > Alexei Fedotov wrote: > >> Technically, both approaches cross JNI-boundary twice. When we raise >> an exception in JNI code, we return back to Java to run its >> constructor, hence cross the boundary. It seems that Tim's approach is >> just more compact which makes it eaiser to write the code without >> bugs. >> >> >> >> On Fri, Dec 5, 2008 at 7:42 PM, Tim Ellison <[EMAIL PROTECTED]> >> wrote: >> >>> 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 >>> >>> >> >> >> > Best Regards, > Regis. >
