|
Error Handling
This has always been a crucial part of any application. In all programs, it's extremely important to handle errors in a sensible, standardized way. If standards for error handling are not in place before coding starts, every programmer will come up with his or her way of doing things. In the worst case scenario, this might mean no error handling at all, and, in the best case, the result will be different ways of handling and reporting errors.
First of all, it must be defined what is meant by an "error." Barring validation errors from the discussion (as they are discussed separately below) "system errors" are serious errors that should not occur when the application is running as planned. If a serious error is detected you should first decide:
- How the application should proceed.
- What information should be given to the end user.
- What information should be given (logged) to other parties.
Then decide how serious errors should be handled technically inside the Java programs themselves. One good method is to use
chained
exceptions. Document in detail how the programmers should write code
for serious errors. Include all common scenarios—errors in external interfaces,
errors in the application's own logic—and remember to cover unchecked
exceptions (like a division by zero). Make test programs that show how the technique works in practice.
Consider identifying all the places in the code where an error is handled by a
unique "key", which can be logged and used for locating the code that handled the error situation. The keys could also be stored in a configuration file
holding data for all error situations.
The information that is logged should include:
- a timestamp
- a precise identification of the module doing the logging
- a message with all important data included
Logging
Primarily, logging is used for logging errors. But it's also used for reporting other things of interest, like performance data and important events like startup and shutdown. A lot of things happen during startup of an application—configuration files are read, connections to external sources are established. It's a good idea to write out detailed information of how these actions are handled.
Standardization should include:
- What is logged.
- Where it's logged: normally, files are used, but logging could go to many targets—email, dedicated listener programs, etc.
- The format of the logged data: care should be taken to ensure that a log message is understandable and complete. Identification of the sender and a timestamp should be considered mandatory.
- The "severities" used for the various items logged.
- How log files are maintained (emptied, backed up, recycled, etc.).
Ideas for a logging framework based on traditional logging APIs will be discussed later.
Application Parameters
The setups of most applications are controlled by a set of parameters. While some parameters may be taken from a database, this is not always convenient because it requires the database setup to be in place before you can use it. Discuss early on which parameters you can use and where you can get them. You may find some ideas in this article."
Unit Testing
Your projects should not only strive to unit test all its Java methods, but also to test all its business functionality—regardless of which classes and methods are involved. Unit testing goes all the way from the back-end to the front-end, including all client programs.
When your goals have been set regarding what your unit testing should cover, it's important to realize that this influences the application design. For example: to test your front-end logic, it's convenient to have a setup that does not need the real back-end, which typically includes a database. You can make a setup like this using "mock objects"—but then you have to design your application to allow using mock objects. The setup is often implemented using interfaces and factories, and if this is done from the beginning, testing becomes much simpler.
A large application needs a large collection of unit test programs, which
means that naming standards should also be in place for the unit test programs
(classes, packages, configuration files, etc.).
When it comes to selecting unit test tools there are a lot to pick from:
Click here for a list of more tools.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
