• (cs) in reply to cklam
    cklam:
    slamb:
    Good developers know that, (1) Exception Handling is costly and might use thousands of CPU cycles to process which, in turn could take several nanoseconds
    Ahem. Good coders know that "thousands of CPU cycles" and "several nanoseconds" are only the same if your processor is running at 1 THz. The current state of the art is more like 1 GHz, and being off by three orders of magnitude on a performance calculation is not cool.

    This time your errors cancel each other out. Exceptions shouldn't take thousands of CPU cycles. Even if they did, if I correctly read your sarcasm, you already know that they probably shouldn't be thrown often enough for several microseconds to be a big deal.

    Alert - Alert - Severe sarcasm detector failure .....

    And (ahem): first on page 2

    I saw the sarcasm. I left you a clue to that effect (hint: it was the part where I mentioned the sarcasm). It's subtle, but try to stay with me here.

    A sprinkling of sarcasm doesn't come with a free pass on total bullshit math. He's trying to (sarcastically, yes) make the point that exceptions are cheap enough to not be worth doing stupid things over, even if this "pattern" helped, which it doesn't. The conclusion happens to be true, but it certainly is not proven by the faulty reasoning.

  • (cs)

    the biggest wtf is of course the non-java coding style.

  • NiceWTF (unregistered) in reply to Stan
    Stan:
    I went a step further than Apache and made a closer that will call close() on anything that has one. If and when somebody needs to handle one of those exceptions, I'll add an exception handler argument.

    Dynamic typing in Java. Nice.

    It must be using reflection then, which means it's probably an order of magnitude slower than normal method calls, while removing the benefits of static typing (compile-time checking for common errors).

    Sounds like you are using the wrong programming language for the job at hand, heh ;)

    (I know..it's not like the decision to use Java was yours, probably)

  • Morty (unregistered) in reply to Look at me! I'm on the internets!
    Look at me! I'm on the internets!:
    I want to close a stream. I can't, because the stream is already closed. This is on par with that classic windows WTF, "Cannot delete foo as there is not enough disk space. Try deleting some files"
    Wrong. close() can fail for networked file systems even if you haven't already closed the file, i.e. if network connectivity to the file server has failed or the file server has gone down. In this case, the exception can be useful.

    Simple example: word processor app implementing file|save. The app writes out all data to the file, but the data isn't actually written across the network yet. Then the file server goes down. Then the app calls close(). The OS tries to finish writing the data across the network, and fails. So the close() fails, and throws an exception. You want to handle this exception, tell the user that the save was not successful, and leave the user's data buffer in a dirty state.

  • Dube (unregistered)

    That one really hurts my heart!

    i have really no idea how someone ever should come to such a stupid solution!

    it does not even have less code lines, the for-loop is completly useless o_0

  • Bozo the Engineer (unregistered)

    This entire thread is really depressing.

    try {
	baos.close();
} catch(IOException ioe) {
	// EMPTY (or log it. can't fix it)
} finally {
	baos = null;		
}
try {
	dos.close();
} catch (IOException ioe) {
	// EMPTY (or log it. can't fix this either)
} finally {
	dos = null;
}

    captcha: cognac. tasty.

  • Peter Lawrey (unregistered)

    Let us assume that baos is a ByteArrayOutputStream and dos is a DataOutputStream and dos is a wrapper for baos, what would happen if we didn't call close at all?

    ByteArrayOutputStream.close()

        // inherited from OutputStream.
    public void flush() throws IOException {
    }

    /**
     * Closing a ByteArrayOutputStream has no effect. The methods in
     * this class can be called after the stream has been closed without
     * generating an IOException.
     * 
    
     *
     */
    public void close() throws IOException {
    }

    And DataOutputStream.close()

        public void flush() throws IOException {
	out.flush();
    }
   /**
     * Closes this output stream and releases any system resources 
     * associated with the stream. 
     * 
    
     * The close method of FilterOutputStream 
     * calls its flush method, and then calls the 
     * close method of its underlying output stream. 
     *
     * @exception  IOException  if an I/O error occurs.
     * @see        java.io.FilterOutputStream#flush()
     * @see        java.io.FilterOutputStream#out
     */
    public void close() throws IOException {
	try {
	  flush();
	} catch (IOException ignored) {
	}
	out.close();
    }

    As you can see dos flushs and closes baos, which all do nothing.

    But imagine that there was a good reason to actually call these methods and they did something important.

    In that case we have called. baos.close(); dos.close(); dos.flush(); baos.flush();

    Note: baos is closed before dos is flushed. So if there was unsaved data in dos and baos prevented a flush after being closed, this would fail.

    In other words, calling these two methods in this order only works because they don't do anything! In which case you could just not call them.

    IMHO: the safest option is just dos.close() and log any exception on the lowest logging level, because if it ever threw an exception it might mean one of your assumptions is wrong.

  • Bob (unregistered)

    Yeah whatever. You are all a bunch of faegoats.

Leave a comment on “Code Reuse”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article