Java Stored Procedures - Expert Oracle and Java Security - page 52

Based on the discussions on exception handling in Chapter 3, we select to catch all exceptions and
deal with them locally, setting the string that we are about to return to be equal to the value returned
from Exception.toString() . When we get to the end of the try / catch / finally blocks, the last line
returns timeString , which may be the Oracle database data and time if successful, else it will be the
Exception.toString() message. (Please note that the toString() method in Exception is not static. You
will need an instance of Exception , like x , to call x.toString() . I'm just saying Exception.toString() for
discussion clarity.)
Here is an example Exception.toString() message:
java.sql.SQLException: Invalid Oracle URL specified.
In the finally block, we close the Statement object, stmt . Again, we are dealing with Oracle
database, so we must be prepared for and catch any SQLExceptions . However, we needn't do anything
with exceptions in this case. Notice that we test to see if stmt is null before we try to close it. That test
will keep us from generating a NullPointerException in case we never instantiated the Statement object.
( NullPointerException is generated when we attempt to use methods or members of a class that has not
been instantiated.) Maybe you already surmised correctly that we don't need to do the test on whether
stmt is null . Since we are in a try / catch block and doing nothing with exceptions, we could just attempt
to close the stmt and it will either succeed or we will catch the NullPointerException . That is true, but I
don't like generating exceptions needlessly, so we test if stmt is null .
Another notable item at this point in our exploration of Java is the declaration of timeString and
stmt . First, notice that we declare (mention) them before the try block. We need to do that so that we
can return timeString outside the try block, and so that we can close the stmt in the finally block,
which is outside the try block. Member variables are contextual, and only reside within the scope of
their declaration. That is to say, a member variable only exists within the block (curly braces) where it is
declared. For example, the ResultSet member does not exist outside of the try block.
The second thing to notice about the declaration of timeString and stmt is that they are both
declared initially to be null . As I mentioned earlier, they would point to no object ( null ) even if we didn't
declare them as null . This is true of all Java objects, not just Strings and Statements. However, the
compiler looks ahead and sees that we are going to return timeString , and it doesn't like to return
unknowns. If you tried to compile a method with these two lines:
String myString;
Return myString;
The compiler will report an error and refuse to compile your code, saying that myString may not
have been initialized (set to point at an object or at a value). But if you change the declaration of
myString to be:
String myString = null;
then the compiler will accept that (at least) you take responsibility for the null value, and it will
compile your code.
You might ask why the compiler doesn't see that timeString is initialized later on (we say timeString
= rs.getString(1) ) when we are reading through the ResultSet ? Javac is a pretty smart compiler. It sees
the initialization there but notices that the initialization occurs conditionally —meaning, it happens after
the if statement.
So, why is stmt declared to be null ? It's for a very similar reason. If you declared stmt like this,
without initializing it even to null ; then, when the compiler looks ahead and sees that you are going to
test stmt in an if block, it reports an error that stmt might not have been initialized.
Statement stmt;
…