Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 12730 invoked from network); 9 Dec 2008 03:33:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Dec 2008 03:33:54 -0000 Received: (qmail 83785 invoked by uid 500); 9 Dec 2008 03:34:05 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 83744 invoked by uid 500); 9 Dec 2008 03:34:05 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 83733 invoked by uid 99); 9 Dec 2008 03:34:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Dec 2008 19:34:05 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xu.regis@gmail.com designates 64.233.170.187 as permitted sender) Received: from [64.233.170.187] (HELO rn-out-0910.google.com) (64.233.170.187) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Dec 2008 03:33:50 +0000 Received: by rn-out-0910.google.com with SMTP id k57so1146763rnd.13 for ; Mon, 08 Dec 2008 19:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DrNJA9duEwBGr8IpFlpCAGvuL5kR3akW5MG1MKa+A4U=; b=Xa3h6Adn4f83oocWG71lgKHGt2PUP2EPYRg7SiwjkAYxnBK8oPyf5wBjc1Db2xY6Rr 9OQLH+nhJGGJfkZoUFY2ZbMjMT64Ddv8zjDbM9DKtiQJfE20WS5U9YiPW30tROJocnTf cI3N/q5fiGKuMRFz+R6L2ocGdaLOfLViiIAnA= 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=S/7eZL9NhLS/HXGFq80xC6ZoqiIdtgKYcdlEUZzEan6JnBQoBlADDQkUL2UWO7eftz jx3iojsVuqrd58uWbAvDmPMQ3S7OmN2KN+zY08wOVKNv2GsjpkfWAea3cR9l4B8RUJRG kw/7ELHQfrJJUJyT8G4m+wL9ULgBB1hBZLGQ8= Received: by 10.150.196.5 with SMTP id t5mr9186891ybf.10.1228793606481; Mon, 08 Dec 2008 19:33:26 -0800 (PST) Received: from ?9.123.233.47? ([220.248.0.145]) by mx.google.com with ESMTPS id a68sm17716902rnc.17.2008.12.08.19.33.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Dec 2008 19:33:25 -0800 (PST) Message-ID: <493DE6FF.5000108@gmail.com> Date: Tue, 09 Dec 2008 11:33:19 +0800 From: Regis 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> <4938D9B3.3080307@gmail.com> <49395A0E.5090009@gmail.com> In-Reply-To: <49395A0E.5090009@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 >>>> 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.