Java Reference
In-Depth Information
It is also usually poor practice to throw a raw exception (though we do
so in this topic to keep things as brief as possible).
The most complete and well-behaving Java code has predictable, logical excep-
tion management. Users and clients of an interface will appreciate the effort.
9.5
Mini-antipatterns: Leaks and performance
This section will depart briefly from design-oriented standards and will visit
some of the rules discussed in chapters 6, 7, and 8
.
They are standards that
help to prevent some of the antipatterns in this topic. The nature of a project's
coding conventions guidelines will determine whether this type of information
is appropriate.
In general
Optimize later. Optimization should be done at the tail end of the
development cycle, with one caveat. If it is absolutely crystal clear that
one area will be a bottleneck, then it should be attacked first and fully
optimized, to allow recovery time. If you need to make code obscure
for the sake of optimization, document the approach.
Leaks and cleanup
Pair code that handles allocation and freeing of resources as closely
together as possible, preferably in the same method.
With collections, objects that are added should be removed as well.
Add
/
remove pairs should remain in close proximity. The primary excep-
tion is a collection that uses weak or soft reference objects, or a collec-
tion that implements a fixed set that will remain fixed or that will grow
throughout the life cycle of the collection. We need to document such
cases clearly.
Looping and round-tripping
EJB
s should be accessed through a common command layer or facade so
that collecting all of the attributes for a bean will not create a round-
tripping situation.
Keep redundant computations outside of loops and loop tests. For
example, do not use this:
for (int i = 0; i <
someCollection.size()
; i++)
