On 24 October 2013 01:16, Gary Gregory <garydgreg...@gmail.com> wrote:
> Hi All:
>
> I see a log of this pattern:
>
> try {
> if (outputStream != null) {
> outputStream.close();
> }
> } catch (final Exception e) {
> Debug.debug(e);
> }
>
> for example in org.apache.commons.imaging.Imaging:
>
> public static void writeImage(final BufferedImage src, final File file,
> final ImageFormat format, final Map<String,Object> params)
> throws ImageWriteException,
> IOException {
> OutputStream os = null;
>
> try {
> os = new FileOutputStream(file);
> os = new BufferedOutputStream(os);
>
> writeImage(src, os, format, params);
> } finally {
> try {
> if (os != null) {
> os.close();
> }
> } catch (final Exception e) {
> Debug.debug(e);
> }
> }
> }
>
> Which seems wrong to me. If I get an IOE while writing, we throw, but if we
> get one when flushing and closing the file (which may also write), we
> swallow it. Why? It seems the IOE from close should percolate up and not be
> swallowed.
I agree that's bad practice - not only because of swallowing the Exception.
The catch block should catch IOException not Exception.
> All of this is moot in Java 7 with try-with-resources blocks but we are not
> ready for Java 7 here I imagine.
>
> Gary
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second
> Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
