Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

OneStatementPerLine should tolerate the Java 7 try-with-resources #64

Closed
isopov opened this Issue Nov 17, 2013 · 5 comments

Comments

Projects
None yet
3 participants
Contributor

isopov commented Nov 17, 2013

The OneStatementPerLine keeps the Java code tidy. However, in Java 7, the new try-with-resources was added, which implies that several Closeable resources can be created within one try statement:

try (Reader xml = toXML(data); Reader xslt = createXSLReader(); WritableByteBuffer out = createOutputBuffer();) {
   ...
} catch (final IOException e) {
  ...
}

OneStatementPerLine should be configurable to tolerate this use case. Or as a more generic solution, allow regexes for exceptions to the rule.

Contributor

isopov commented Nov 17, 2013

Personally, I am against this feature since every assignment inside try-statement is actually creation of the new Autocloseable resource, it is a separate statement, so it seems to me that OneStatementPerLine enforcement should enforce this case to be like

try (Reader xml = toXML(data); 
    Reader xslt = createXSLReader(); 
    WritableByteBuffer out = createOutputBuffer();)    {
   ...
} catch (final IOException e) {
  ...
}

Which is the case currently.

Owner

romani commented Nov 18, 2013

@isopov , I am with you, do not see any reason in such request.
If author still feel strong in his opinion please welcome to mail-list for discussion with exact examples of code - https://groups.google.com/forum/?hl=en#!forum/checkstyle

@romani romani closed this Nov 18, 2013

philipa commented Sep 18, 2015

I agree with the above, but this fails OneStatementPerLine for me:

        try (
            OutputStream fos = new FileOutputStream("foo");
            OutputStream fos2 = new FileOutputStream("bah");) {
        }
Owner

romani commented Sep 18, 2015

@philipa, please create new issue for your case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment