harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Zhou" <zhoukevi...@gmail.com>
Subject Re: [classlib] [luni] Should Improve File System Exception Messages
Date Mon, 08 Dec 2008 08:09:06 GMT
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 <xu.regis@gmail.com> 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 <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,
> Regis.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message