You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2008/12/05 17:42:54 UTC
[classlib] [luni] Should Improve File System Exception Messages
Regis wrote:
> Jim Yu wrote:
>> 2008/12/5 Regis <xu...@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
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Regis <xu...@gmail.com>.
Hi Tim,
Thanks your advice, I'll refine the patch.
Tim Ellison wrote:
> 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.
>
> HYPORT_ERROR_* messges are platform independent so you can pass them
> around in common code.
>
> You should not use hyfile_error_message() since it is not thread safe -
> i.e. you might get back an error/success for a different thread's file
> operation. Its use is deprecated.
>
>> 2. error messages are hard coded in netLookupErrorString, is that expected?
>
> That is used to map from the HYPORT_ERROR_* messages to a display
> string, so yes it is expected, but maybe not what we want to use here.
>
> In general, portlib functions that make OS calls set a per-thread error
> code (using hyerror_set_last_error()), and the users of the portlib
> retrieve it using hyerror_last_error_number() and the corresponding
> display string using hyerror_last_error_message().
>
> Take a look at the portlib functions in hyerror.c
>
> Regards,
> Tim
>
>
>
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Tim Ellison <t....@gmail.com>.
Tim Ellison wrote:
> Take a look at the portlib functions in hyerror.c
Now documented here
http://harmony.apache.org/externals/vm_doc/html/hyerror_8c.html
Regards,
Tim
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Regis <xu...@gmail.com>.
I attached a new patch which use hyerror_last_error_message instead of
hyfile_error_message, anyone want to try/review it?
Tim Ellison wrote:
> 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.
>
> HYPORT_ERROR_* messges are platform independent so you can pass them
> around in common code.
>
> You should not use hyfile_error_message() since it is not thread safe -
> i.e. you might get back an error/success for a different thread's file
> operation. Its use is deprecated.
>
>> 2. error messages are hard coded in netLookupErrorString, is that expected?
>
> That is used to map from the HYPORT_ERROR_* messages to a display
> string, so yes it is expected, but maybe not what we want to use here.
>
> In general, portlib functions that make OS calls set a per-thread error
> code (using hyerror_set_last_error()), and the users of the portlib
> retrieve it using hyerror_last_error_number() and the corresponding
> display string using hyerror_last_error_message().
>
> Take a look at the portlib functions in hyerror.c
>
> Regards,
> Tim
>
>
>
--
Best Regards,
Regis.
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Tim Ellison <t....@gmail.com>.
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.
HYPORT_ERROR_* messges are platform independent so you can pass them
around in common code.
You should not use hyfile_error_message() since it is not thread safe -
i.e. you might get back an error/success for a different thread's file
operation. Its use is deprecated.
> 2. error messages are hard coded in netLookupErrorString, is that expected?
That is used to map from the HYPORT_ERROR_* messages to a display
string, so yes it is expected, but maybe not what we want to use here.
In general, portlib functions that make OS calls set a per-thread error
code (using hyerror_set_last_error()), and the users of the portlib
retrieve it using hyerror_last_error_number() and the corresponding
display string using hyerror_last_error_message().
Take a look at the portlib functions in hyerror.c
Regards,
Tim
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Sean Qiu <se...@gmail.com>.
Grad to learn too.Thank you for your explanation.
2008/12/9 Tim Ellison <t....@gmail.com>
> Regis wrote:
> > I have attached a patch for this issue on JIRA.
>
> See comments elsewhere why the patch needs some tweaking.
>
> > 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!
>
> A code sample would be helpful to ensure I understand your situation
> correctly.
>
> But the 'throw' in native code does not cause a function return (think
> of it as marking a pending throw upon return [1]). The ThrowNew JNI
> call will copy the message string into a new Java String object, so you
> can free it before the native returns, i.e.
>
> allocate memory
> throw exception
> free memory
> return from native (causes throw to occur)
>
> Of course, you can also just use a local var rather than allocate if you
> want too.
>
> Make sense?
> Tim
>
> [1] It's important to understand this, otherwise you'll be surprised
> about code running after your "native throw". As a rule, you should
> tidy-up and return quite soon after raising the exception for clarity.
>
--
Best Regards
Sean, Xiao Xia Qiu
China Software Development Lab, IBM
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Regis <xu...@gmail.com>.
Gregory Shimansky wrote:
> Regis said the following on 10.12.2008 7:46:
>>
>>
>> Tim Ellison wrote:
>>> Regis wrote:
>>>> I have attached a patch for this issue on JIRA.
>>>
>>> See comments elsewhere why the patch needs some tweaking.
>>>
>>>> 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!
>>>
>>> A code sample would be helpful to ensure I understand your situation
>>> correctly.
>> For example, the system message is "No such file or directory", I just
>> like to append file path, like "No such file or directory: /home/a/c",
>> so I need a new block of memory for holding the new string.
>>>
>>> But the 'throw' in native code does not cause a function return (think
>>> of it as marking a pending throw upon return [1]). The ThrowNew JNI
>>> call will copy the message string into a new Java String object, so you
>>> can free it before the native returns, i.e.
>> That's a little surprise, I need to refresh my head about the native
>> code. Where can I find such details of JNI call? It seems JNI spec is
>> so brief that I can't find more useful things.
>
> There is a "book" from Sun that is more detailed than JNI spec:
> http://java.sun.com/docs/books/jni/html/jniTOC.html
>
Great, thanks Gregory!
--
Best Regards,
Regis.
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Gregory Shimansky <gs...@apache.org>.
Regis said the following on 10.12.2008 7:46:
>
>
> Tim Ellison wrote:
>> Regis wrote:
>>> I have attached a patch for this issue on JIRA.
>>
>> See comments elsewhere why the patch needs some tweaking.
>>
>>> 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!
>>
>> A code sample would be helpful to ensure I understand your situation
>> correctly.
> For example, the system message is "No such file or directory", I just
> like to append file path, like "No such file or directory: /home/a/c",
> so I need a new block of memory for holding the new string.
>>
>> But the 'throw' in native code does not cause a function return (think
>> of it as marking a pending throw upon return [1]). The ThrowNew JNI
>> call will copy the message string into a new Java String object, so you
>> can free it before the native returns, i.e.
> That's a little surprise, I need to refresh my head about the native
> code. Where can I find such details of JNI call? It seems JNI spec is so
> brief that I can't find more useful things.
There is a "book" from Sun that is more detailed than JNI spec:
http://java.sun.com/docs/books/jni/html/jniTOC.html
--
Gregory
Re: [general] JNI programming
Posted by Kevin Zhou <zh...@gmail.com>.
:)
On Wed, Dec 10, 2008 at 6:06 PM, Regis <xu...@gmail.com> wrote:
>
>
> Kevin Zhou wrote:
>
>> Thanks for sharing, Regis.
>>
> It's sharing from Tim, I just following closel ;)
>
>
>> On Wed, Dec 10, 2008 at 5:02 PM, Regis <xu...@gmail.com> wrote:
>>
>>
>>> Tim Ellison wrote:
>>>
>>> Regis wrote:
>>>>
>>>> That's a little surprise, I need to refresh my head about the native
>>>>> code. Where can I find such details of JNI call? It seems JNI spec is
>>>>> so
>>>>> brief that I can't find more useful things.
>>>>>
>>>>> There are books on JNI programming.
>>>>
>>>> I like "Essential JNI" by Rob Gordon [1] -- its worth reading cover to
>>>> cover as it has practical code samples and a reference section.
>>>>
>>>> Thanks for sharing, it's interesting.
>>>
>>> I feel a wiki "bookshelf" page coming on... :-)
>>>>
>>>> [1]
>>>> http://www.amazon.com/Essential-Jni-Java-Native-Interface/dp/0136798950
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>
>>>>
>>
Re: [general] JNI programming
Posted by Regis <xu...@gmail.com>.
Kevin Zhou wrote:
> Thanks for sharing, Regis.
It's sharing from Tim, I just following closel ;)
>
> On Wed, Dec 10, 2008 at 5:02 PM, Regis <xu...@gmail.com> wrote:
>
>>
>> Tim Ellison wrote:
>>
>>> Regis wrote:
>>>
>>>> That's a little surprise, I need to refresh my head about the native
>>>> code. Where can I find such details of JNI call? It seems JNI spec is so
>>>> brief that I can't find more useful things.
>>>>
>>> There are books on JNI programming.
>>>
>>> I like "Essential JNI" by Rob Gordon [1] -- its worth reading cover to
>>> cover as it has practical code samples and a reference section.
>>>
>> Thanks for sharing, it's interesting.
>>
>>> I feel a wiki "bookshelf" page coming on... :-)
>>>
>>> [1]
>>> http://www.amazon.com/Essential-Jni-Java-Native-Interface/dp/0136798950
>>>
>>> Regards,
>>> Tim
>>>
>>>
>
Re: [general] JNI programming
Posted by Kevin Zhou <zh...@gmail.com>.
Thanks for sharing, Regis.
On Wed, Dec 10, 2008 at 5:02 PM, Regis <xu...@gmail.com> wrote:
>
>
> Tim Ellison wrote:
>
>> Regis wrote:
>>
>>> That's a little surprise, I need to refresh my head about the native
>>> code. Where can I find such details of JNI call? It seems JNI spec is so
>>> brief that I can't find more useful things.
>>>
>>
>> There are books on JNI programming.
>>
>> I like "Essential JNI" by Rob Gordon [1] -- its worth reading cover to
>> cover as it has practical code samples and a reference section.
>>
> Thanks for sharing, it's interesting.
>
>>
>> I feel a wiki "bookshelf" page coming on... :-)
>>
>> [1]
>> http://www.amazon.com/Essential-Jni-Java-Native-Interface/dp/0136798950
>>
>> Regards,
>> Tim
>>
>>
Re: [general] JNI programming
Posted by Regis <xu...@gmail.com>.
Tim Ellison wrote:
> Regis wrote:
>> That's a little surprise, I need to refresh my head about the native
>> code. Where can I find such details of JNI call? It seems JNI spec is so
>> brief that I can't find more useful things.
>
> There are books on JNI programming.
>
> I like "Essential JNI" by Rob Gordon [1] -- its worth reading cover to
> cover as it has practical code samples and a reference section.
Thanks for sharing, it's interesting.
>
> I feel a wiki "bookshelf" page coming on... :-)
>
> [1] http://www.amazon.com/Essential-Jni-Java-Native-Interface/dp/0136798950
>
> Regards,
> Tim
>
Re: [general] JNI programming (was: Re: [classlib] [luni] Should Improve File System Exception Messages)
Posted by Jim Yu <ju...@gmail.com>.
Thanks Tim! A good sharing. I took a look at the index and found it is very
helpful for JNI reference.
What a pity, I can't find it from online book stores of China.
2008/12/10 Tim Ellison <t....@gmail.com>
> Regis wrote:
> > That's a little surprise, I need to refresh my head about the native
> > code. Where can I find such details of JNI call? It seems JNI spec is so
> > brief that I can't find more useful things.
>
> There are books on JNI programming.
>
> I like "Essential JNI" by Rob Gordon [1] -- its worth reading cover to
> cover as it has practical code samples and a reference section.
>
> I feel a wiki "bookshelf" page coming on... :-)
>
> [1]
> http://www.amazon.com/Essential-Jni-Java-Native-Interface/dp/0136798950
>
> Regards,
> Tim
>
--
Best Regards,
Jim, Jun Jie Yu
China Software Development Lab, IBM
Re: [general] JNI programming (was: Re: [classlib] [luni] Should Improve File System Exception Messages)
Posted by Sean Qiu <se...@gmail.com>.
2008/12/10 Tim Ellison <t....@gmail.com>
> Regis wrote:
> > That's a little surprise, I need to refresh my head about the native
> > code. Where can I find such details of JNI call? It seems JNI spec is so
> > brief that I can't find more useful things.
>
> There are books on JNI programming.
> I like "Essential JNI" by Rob Gordon [1] -- its worth reading cover to
> cover as it has practical code samples and a reference section.
>
Can I borrow your copy? :-)
> I feel a wiki "bookshelf" page coming on... :-)
>
+1
>
> [1]
> http://www.amazon.com/Essential-Jni-Java-Native-Interface/dp/0136798950
>
> Regards,
> Tim
>
--
Best Regards
Sean, Xiao Xia Qiu
China Software Development Lab, IBM
[general] JNI programming (was: Re: [classlib] [luni] Should Improve
File System Exception Messages)
Posted by Tim Ellison <t....@gmail.com>.
Regis wrote:
> That's a little surprise, I need to refresh my head about the native
> code. Where can I find such details of JNI call? It seems JNI spec is so
> brief that I can't find more useful things.
There are books on JNI programming.
I like "Essential JNI" by Rob Gordon [1] -- its worth reading cover to
cover as it has practical code samples and a reference section.
I feel a wiki "bookshelf" page coming on... :-)
[1] http://www.amazon.com/Essential-Jni-Java-Native-Interface/dp/0136798950
Regards,
Tim
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Regis <xu...@gmail.com>.
Tim Ellison wrote:
> Regis wrote:
>> I have attached a patch for this issue on JIRA.
>
> See comments elsewhere why the patch needs some tweaking.
>
>> 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!
>
> A code sample would be helpful to ensure I understand your situation
> correctly.
For example, the system message is "No such file or directory", I just
like to append file path, like "No such file or directory: /home/a/c",
so I need a new block of memory for holding the new string.
>
> But the 'throw' in native code does not cause a function return (think
> of it as marking a pending throw upon return [1]). The ThrowNew JNI
> call will copy the message string into a new Java String object, so you
> can free it before the native returns, i.e.
That's a little surprise, I need to refresh my head about the native
code. Where can I find such details of JNI call? It seems JNI spec is so
brief that I can't find more useful things.
>
> allocate memory
> throw exception
> free memory
> return from native (causes throw to occur)
>
> Of course, you can also just use a local var rather than allocate if you
> want too.
>
> Make sense?
> Tim
>
Thanks Tim, that's very clear :)
> [1] It's important to understand this, otherwise you'll be surprised
> about code running after your "native throw". As a rule, you should
> tidy-up and return quite soon after raising the exception for clarity.
>
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Tim Ellison <t....@gmail.com>.
Regis wrote:
> I have attached a patch for this issue on JIRA.
See comments elsewhere why the patch needs some tweaking.
> 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!
A code sample would be helpful to ensure I understand your situation
correctly.
But the 'throw' in native code does not cause a function return (think
of it as marking a pending throw upon return [1]). The ThrowNew JNI
call will copy the message string into a new Java String object, so you
can free it before the native returns, i.e.
allocate memory
throw exception
free memory
return from native (causes throw to occur)
Of course, you can also just use a local var rather than allocate if you
want too.
Make sense?
Tim
[1] It's important to understand this, otherwise you'll be surprised
about code running after your "native throw". As a rule, you should
tidy-up and return quite soon after raising the exception for clarity.
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Regis <xu...@gmail.com>.
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...@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.
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Regis <xu...@gmail.com>.
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...@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.
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Kevin Zhou <zh...@gmail.com>.
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...@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....@gmail.com>
>> wrote:
>>
>>> Regis wrote:
>>>
>>>> Jim Yu wrote:
>>>>
>>>>> 2008/12/5 Regis <xu...@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.
>
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Regis <xu...@gmail.com>.
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....@gmail.com> wrote:
>> Regis wrote:
>>> Jim Yu wrote:
>>>> 2008/12/5 Regis <xu...@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.
Re: [classlib] [luni] Should Improve File System Exception Messages
Posted by Alexei Fedotov <al...@gmail.com>.
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....@gmail.com> wrote:
> Regis wrote:
>> Jim Yu wrote:
>>> 2008/12/5 Regis <xu...@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
>
--
С уважением,
Алексей Федотов,
ЗАО «Телеком Экспресс»