Secure Java Development Concepts - Expert Oracle and Java Security - page 47

Consider Throwing A Generic Exception
For web applications, I have used the approach of throwing generic exceptions. No matter how deep you
are in an application's methods, when you catch an exception, you deal with it, and then throw a generic
application exception. The exception you throw is nothing special - it is an ordinary exception that
extends Exception perhaps, but has no other members.
Why would you create such a façade as a generic exception? We need something simple and unique
to our application that we can use like a flag. The generic exception is a flag that lets us know that we
have already dealt with the exception and are just notifying the chain of command. In all application
methods, no matter how deep, you also catch this generic application exception. Let's call this façade
exception GenAppException . Your standard try / catch syntax would look like this:
try {
…
} catch( GenAppException g ) {
throw g;
} catch( Exception x ) {
// Deal with x
throw new GenAppException();
} finally{
…
}

The thing to note here is that no matter what exception we catch here, if we can't just ignore it, we
end up throwing a GenAppException . We either throw the GenAppException we caught from some deeper
level, or we throw a new one.
You know two things when you catch one of these generic application exceptions:

• There was an exception that we need to take note of.

It was handled earlier in the code, so all we need to do is pass it along (throw it).
And here is the clincher: when you get to the top level, ready to present something from the web
application to the user's browser, you catch any exception and present a sensible error page to the user.
They don't want to read your stack trace or exception details, and displaying that data might be a
security concern. All that information should have been logged or e-mailed to the system administrator
or application programmer when you initially dealt with the original exception.

•

Close Local Resources in a finally Block
We have already discussed this in our example code. Let me conclude by saying that every time you
open a database Connection , Statement, or ResultSet , you need to embed the open() and all use of that
resource in a try block, and close the resource in the associated finally block. This rule applies not only
to Oracle Connections , but also to Files , Buffers , Streams , and so on.

Java Virtual Machine Sandbox
We have already explored the JVM and seen that it is the interface between the compiled Java byte code
and the particular machine hardware and operating system where it is running. This gives Java byte code
the ability to “run anywhere”—anywhere there is a JVM, that is.