Database Reference
In-Depth Information
example, you are passing a phone number that you selected from Oracle database to a Java method that
formats phone numbers with parentheses and dashes (e.g., (800)555-1212). However, the current record
has a
null
phone number. You wouldn't want to throw an exception for that trivial concern. You can do
one of 2 things (or both):
Test if the incoming phone number is
null
and immediately return a blank
String.
1.
2.
Format whatever, and if it throws an exception, return a blank
String
—but
don't throw an exception from your phone number format method.
Why wouldn't you just take approach number (1)? Well there might be other problems with
formatting a phone number besides a
null
value. What if the phone number is too short or contains
alphabetic characters? Therefore, to prevent throwing an exception for this simple formatting problem,
we would prefer approach number (2).
Note that this example is for data coming from a database, if you
were dealing with user input, you would probably want to notify the user of format problems so they
could fix them.
Give Feedback from Your Catch Block
Some exceptions need to be documented and communicated, especially in those cases where a system
administrator needs to take immediate action to correct an error, or when the application programmer
needs to fix a processing problem. In those cases, sufficient situational details (like the stack trace and
the data being processed) need to be transmitted. There are three common ways to transmit the data:
•
Log it in an error log file or database.
•
Send an e-mail or other message to an on-call support address.
•
Print a message to the console or application window.
In client/server applications, the application user is rarely the person who needs to get the error
details, so sending that data to the console or application window will not help solve the problem, but
you do need to inform the user that there is a problem, with a sensible message like, “An error has
occurred. We have informed the administrator. Please try again later. Thank you.”
If an error is not likely to be urgent, you might rely on logging the details and hope the administrator
reviews the logs at some time; otherwise, you may need to send a message directly to the administrator
by e-mail or some other messaging system.
Govern the Amount of Exception Reporting in Any Major Outage
When catching exceptions and logging or sending e-mails or other messages, beware of the potential to
make the problem worse by excessively reporting the problem. When everyone in your organization
runs into the same problem at the same time, you don't want your administrator's e-mail to fill up
immediately with 1,000 or 10,000 of the exact same error messages. You need to govern the flow.
My approach (not detailed here) is to send the first 10 identical messages, then every tenth in the
first hundred, then every hundredth. In this way, the administrator gets less than 30 messages, even if
1,000s are generated.
