By sharvil
via sharvil.nanavati.net
Submitted: Mar 02 2008 / 15:16
When I release a resource, I really don't want to hear back from it. Java's standard library doesn't follow this rather simple principle and can result in some subtle bugs. If you design reusable code, take a look and make sure you don't fall into the same trap.
SaveShareSend
Tags: java, methodology, other languages
-
Java Named parameters
-
First Look at Cappuccino and Objective-J
-
command line encryption and decryption with openssl, perfect for your aim logs :)
-
Developing for the Rich Client Platform, the Ganymede way
-
Updating additional data fields in has and belongs to many relationship
-
What Can You Do With a Virtual Team?
Comments
dkharlamov replied ago:
Yes and no. Checked exception is a good way to let programmer know about any issues with certain resource. On the other hand you did find good example to be improved on Java side. But I would still have those checked exceptions as you may have "connected" resources (which should be closed one after another) or so.
sharvil replied ago:
I agree that checked exceptions are a great way to notify the caller of problems with the resource. However, I don't think it's reasonable to force the caller to take action (via checked or unchecked exception) when the caller has declared that it has no more interest in the resource. For methods that acquire and interact with resources, I agree with you wholeheartedly.
dzonelurker replied ago:
Warning: defective code!
sharvil replied ago:
Hey there, dzonelurker. Could you please elaborate on your comment? The first snippet is intentionally defective and I explain why that sort of code should be avoided. I'd be more than happy to revise the second snippet but I can't spot any problem with it (unless 'close' throws a RuntimeException which is not the point of the illustration and would just increase clutter without adding value).
Voters For This Link (2)
Voters Against This Link (1)