harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [classlib] [luni] Should Improve File System Exception Messages
Date Mon, 08 Dec 2008 02:54:34 GMT
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 <t.p.ellison@gmail.com> wrote:
>> Regis wrote:
>>> Jim Yu wrote:
>>>> 2008/12/5 Regis <xu.regis@gmail.com>
>>>>> 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,

View raw message