Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xu.regis@gmail.com designates
 209.85.217.12 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=I76kbfy9+SxhWGM+V/tU+Pu3WVW/5Zjv0A8sTPWEBG5uL73ZqUIZLjo75nwlvkYKjI
         3b/8ILH+Mqhx6dfWZu9/KuNwyeN18F7WI8Qgjh3Sib4tXH1SnWEpkG8I+jvloOJ8KkkV
         4rvDNqaqqducN/CL/RfY5JpHQSQse1KEALODw=
Message-ID: <493E5EBB.1020105@gmail.com>
Date: Tue, 09 Dec 2008 20:04:11 +0800
From: Regis <xu.regis@gmail.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib] [luni] Should Improve File System Exception Messages
References: <297100561.1228445444854.JavaMail.jira@brutus>
	 <70c713190812041903i5ca0920agee58291279d007fd@mail.gmail.com>
	 <4938AE77.80706@gmail.com>
 <c8963150812042200n6d87c269oa54062b840de474b@mail.gmail.com>
 <4938D9B3.3080307@gmail.com> <49395A0E.5090009@gmail.com>
 <493DE6FF.5000108@gmail.com>
In-Reply-To: <493DE6FF.5000108@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I have attached a patch for this issue on JIRA.

I think that would be helpful to add file path in error messages when 
throw FileNotFoundException, and that need to allocate new memory for 
the new messages, I used hymem_allocate_memory to do this. But I don't 
have chance to free that memory, since exception thrown, code back to 
java. That may cause memory leak, I know define a enough large char 
array could avoid this, but need more memory (path may be very long), is 
there any other better way to do this? Thanks!

Regis wrote:
> I found readImpl and writeImpl in OSFileSystem.c use
> 
> netLookupErrorString(env, HYPORT_ERROR_FILE_LOCKED)
> 
> to get error messages, which are hard coded in nethelp.c, my questions are:
> 
> 1. why does file read/write need to get error messages from nethelp.c? 
> We already have hyfile_error_message() can do that.
> 
> 2. error messages are hard coded in netLookupErrorString, is that expected?
> 
> 
> Tim Ellison 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.
> 

Best Regards,
Regis.