Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: unnecessary code in Oracle example?
Date: Wed, 09 Oct 2013 21:11:21 +0200
Lines: 102
Message-ID: <bblo2qFqgc8U1@mid.individual.net>
References: <ydnr4bujt72.fsf@shell.xmission.com> <u6h5u.69447$yx6.64233@fx26.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 04t+zYL9f9LqScg/AJB+2g3NnEUL+6APrUnTne0udHTQaE8+s=
Cancel-Lock: sha1:/poAM/tsHPYucnmiqS6xW0th7vs=
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
In-Reply-To: <u6h5u.69447$yx6.64233@fx26.iad>
Xref: csiph.com comp.lang.java.programmer:26258

On 10/09/2013 08:19 PM, Daniel Pitts wrote:
> On 10/9/13 9:38 AM, Jim Janney wrote:
>> I'm reading up on Java 7's try-with-resource statement and looking at
>> the tutorial at
>>
>> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
>>
>>
>> which includes the following code:
>>
>>> static String readFirstLineFromFileWithFinallyBlock(String path)
>>>                                                     throws IOException {
>>>     BufferedReader br = new BufferedReader(new FileReader(path));
>>>     try {
>>>         return br.readLine();
>>>     } finally {
>>>         if (br != null) br.close();
>>>     }
>>> }
>>
>> As a matter of habit, I always write that pattern as
>>
>>
>>> static String readFirstLineFromFileWithFinallyBlock(String path)
>>>                                                      throws
>>> IOException {
>>>     BufferedReader br = new BufferedReader(new FileReader(path));
>>>     try {
>>>         return br.readLine();
>>>     } finally {
>>>         br.close();
>>>     }
>>> }
>>
>> on the theory that if you reach that point br can never be null, so the
>> test is both redundant and confusing.  On the other hand, I might be
>> wrong.  Is there a reason to test for null in the finally block?

If you declare the variable "final" then there is no reason.  The way 
you showed it "br" can actually become null.

> You are correct for this case, the other case comes from a block which
> uses multiple resources.
>
> MyResource r1 = null;
> MyResource r2 = null;
>
> try {
>    r1 = openResource1();
>    r2 = openResource2();
> } finally {
>    if (r1 != null) r1.close();
>    if (r2 != null) r2.close();
> }
>
> Of course, some close() methods can throw, which could break this idiom
> too.

The proper (i.e. robust) way to do it would be to spend one try finally 
block per resource.  That may not be the prettiest of idioms because of 
the indentation but it's robust.

> This is one reason why C++ forbids destructors from throwing.

Does it?

$ cat -n x.cxx
      1	
      2	
      3	#include <iostream>
      4	
      5	class Ex {
      6	};
      7	
      8	class Foo {
      9	  public:
     10	  ~Foo() throw (Ex) {
     11	     std::cout << "destructor" << std::endl;
     12	     throw Ex();
     13	  }
     14	};
     15	
     16	int main() {
     17	  try {
     18	    Foo f;
     19	    std::cout << "foo" << std::endl;
     20	  }
     21	  catch (Ex e) {
     22	    std::cout << "caught" << std::endl;
     23	  }
     24	
     25	  return 0;
     26	}
     27	
robert@fussel:~$ g++ x.cxx && ./a.out
foo
destructor
caught

Cheers

	robert