Database Reference
In-Depth Information
Notice that we open a
synchronized
block before our added
try
block, and we close the
synchronized
block (with an extra close curly bracket) after our added
finally
block. Everything within that
synchronized
block will be executed exclusively by one call to the
methodName()
method (by one user) at
a time.
We are synchronizing on a blank
String
named
synchOnThis
. It is a
static
class member. Let me point
out how we might capitalize on this synchronization arrangement. Let's say we have an additional method
in this same class that we need to debug. We can add identical
try
/
finally
blocks and debugging in that
second method, again synchronizing on the
synchOnThis
member. Not only will each call to those
methods get exclusive access to write to our file, but also a call to either method will have exclusive
access—e.g., someone in our first method cannot have access to the file while someone in the second
method has
synchronized
on it. If you want to debug a method in a different class to this same file, you
can synchronize on the same static member,
synchOnThis
in this class.
There is one assumption in synchronization that you must understand: synchronization is only effective
within a single JVM. If you have, for example, two web servers on the same computer, each one will likely
be running its own JVM. Those two JVMs cannot coordinate synchronized access to a file (for example). So
if one of the JVMs is writing to the file, the other JVM may try to write to the file at the same time. That will
likely fail.
Exception Handling Approaches
There are a variety of philosophies and practices regarding exception handling. I have not seen any
proposals that I have entirely agreed with. However, I do have practices that I like, and I do try to be
consistent. Allow me to propose a few ideas that help define my approach.
Don't Code Multiple Exceptions When One Will Do
I find that it is a very rare circumstance that will provoke me to do one thing for one specific exception
thrown in a
try
block, and a different thing for another kind of exception in the same block. So I usually
only have one
catch
block per
try
block. One “exception” to this rule is when I am throwing generic app
exceptions (more on this is a bit).
Additionally, I will frequently have
try
and
catch
blocks inside other
try
and
finally
blocks. You
have already seen me do that in the
finally
block listed previously.
Catch and Handle an Exception Where It Occurs
Deal with the exception immediately. If you're not sure what to do in the current method, it will be even
harder to do something from a more remote method. An “exception” to this is when your design is
intended to throw exceptions in order to create a complete stack trace.
I'm thankful that the classes provided by Sun and Oracle corporations are designed to throw their
exceptions to my code. They are certainly not in a position to handle them like I as the application
programmer can. But it's true for you like it's true for me, what my graduate professor once said: “You're
the doctor now.” It's your job to deal with the exception.
It almost goes without saying that there are many times when the best way to deal with an exception
is to ignore it. One way I frequently ignore exceptions is by returning a blank
String
. Let's say, for
