Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <896956.478031285857753470.JavaMail.jira@thor>
Date: Thu, 30 Sep 2010 10:42:33 -0400 (EDT)
From: "Niall Pemberton (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Issue Comment Edited: (IO-249) Enhance closeQuietly to
 indicate success
In-Reply-To: <31987904.459261285748396247.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/IO-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916488#action_12916488 ] 

Niall Pemberton edited comment on IO-249 at 9/30/10 10:42 AM:
--------------------------------------------------------------

@Joerg - I like the fact that Commons IO has no dependencies - that and with the popularity of things like SLF4J I really wouldn't want to add commons-logging as a dependency. Also with the introduction of the java.io.Closeable interface in JDK 1.5 then there is now only the need for one closeQueitly() method, rather than all the flavours Commons IO has - so anyone who wants their own custom impl - for example using their preferred logging framework - can easily do so.

@Paul - even though I disagreed with this for compatibility reasons - I actually don't like the proposal and would oppose it anyway. It just seems wrong to *return* an exception rather than throwing it, it encourages people to write strange code and the benefit diminishes since instead of replacing 4 lines with 1 line, you're now replacing 4 lines with 3:

So instead of having:

{code}
try {
    input.close();
} catch (Exception ex) {
    // do something here
}
{code}

You now have:

{code}
IOException ex = IOUtils.close(input);
if (ex != null) {
    // do something here
}
{code}

IMO users would be better off doing it the traditional way with a try/catch rather than this

      was (Author: niallp):
    @Joerg - I like the fact that Commons IO has no dependencies - that and with the popularity of things like SLF4J I really wouldn't want to add commons-logging as a dependency. Also with the introduction of the java.io.Closeable interface in JDK 1.5 then there is now only the need for one closeQueitly() method, rather than all the flavours Commons IO has - so anyone who wants their own custom impl - for example using their preferred logging framework - can easily do so.

@Paul - even though I disagreed with this for compatibility reasons - I actually don't like the proposal and would oppose it anyway. It just seems wrong to *return* an exception rather than throwing it, it encourages people to write strange code and the benefit diminishes since instead of replacing 4 lines with 1 line, you're now replacing 4 lines with 3:

So instead of having:

{code}

        try {
            input.close();
        } catch (Exception ex) {
            // do something here
        }
{code}

You now have:

{code}

        IOException ex = IOUtils.close(input);
        if (ex != null) {
            // do something here
        }
{code}

IMO users would be better off doing it the traditional way with a try/catch rather than this
  
> Enhance closeQuietly to indicate success
> ----------------------------------------
>
>                 Key: IO-249
>                 URL: https://issues.apache.org/jira/browse/IO-249
>             Project: Commons IO
>          Issue Type: Improvement
>          Components: Utilities
>    Affects Versions: 2.0
>            Reporter: Paul Benedict
>            Assignee: Paul Benedict
>            Priority: Minor
>             Fix For: 2.x
>
>
> A convention of some programmers is to emit a log warning when a resource fails to close. Granted, such a condition is an error, but there's no reasonable recourse to the failure. Using IOUtils.closeQuietly() is very useful but all information about the success/failure is hidden. Returning Throwable will give insight into the error for diagnostic purposes. This change will be compatible with today's usage since the method currently returns void.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.