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 <[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.
Best Regards,
Regis.
