>>The flush really is not needed. If removing a call to the flush method
introduces an issue, the real issue really is a missing call to close.
Therefore there is* finally block* because the *#close()* is called anyway
if placed in *finally block*, even if the read/write/close/flush threw an
exception before the finally block.
This is guarantee that whatever I place between try {...} , e.g
*return *or *throw
*exception except for System.exit or Runtime.halt, I have 100% guarantee
that finally block is executed anyway.
If I place close() in finally, everything is okay. That's why Java 7
feature "try-with-resources" compiles Java 7 code to using finally in
bytecode however it does not exist in source code.
On Sun, Jan 8, 2017 at 3:49 AM, Christian Schulte [via Maven] <
[email protected]> wrote:
> Am 01/08/17 um 03:28 schrieb Tibor Digana:
> > As an example flush() is missing in RunEntryStatisticsMap.java L130.
> > Maybe I would find more but this is not the only case. There are 24
> files
> > changed.
>
> It's not missing there. Close is guaranteed to perform a flush implicitly.
>
> resource.flush();
> resource.close();
>
> The flush really is not needed. If removing a call to the flush method
> introduces an issue, the real issue really is a missing call to close.
> There seems to be one case for which an IT is failing now. The IT is
> forcing an OutOfMemoryError and due to missing flush calls, some file is
> empty or not even created at all, because that error isn't handled
> correctly (there somewhere is a missing finally block to ensure open
> resources are cleaned up correctly). No flush -> OutOfMemoryError -> no
> call to close anywhere so no flushes performed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5891905&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5891905&i=1>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Lets-talk-about-our-
> changes-openly-maven-surefire-git-commit-SUREFIRE-1324-
> Surefire-incorrectly-supp-tp5891058p5891905.html
> To start a new topic under Maven Developers, email
> [email protected]
> To unsubscribe from Maven Developers, click here
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> .
> NAML
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context:
http://maven.40175.n5.nabble.com/Lets-talk-about-our-changes-openly-maven-surefire-git-commit-SUREFIRE-1324-Surefire-incorrectly-supp-tp5891058p5891931.html
Sent from the Maven Developers mailing list archive at Nabble.com.
