|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 5
Unfortunately, Java's assertion facility does not mesh with the standard documentation system as closely as the exception
facility. The Javadoc system includes information regarding all throws clauses declared by a method. Assertions do not draw such direct attention. This is certainly sensible for assertions in
general, but rather unfortunate when using assertions to check the validity of input arguments to a public method. Though
using assertions to check input arguments contends with the current Java convention of using exceptions for such checks, I
argue below that assertions are more appropriate. Before entertaining that argument, I state a pedagogic point in using assertions.
A first point in using assertions initially appears tautological: be assertive with assertions. Assertions are often described as something a programmer believes to be true during program execution. Believes is not strong enough. Proclaims sounds nice, but in actual fact, demands is more appropriate. Assertions help define the boundaries of correct system behavior, and as such, warrant a strong, consistent approach.
This point is primarily a psychological issue. The boolean-typed expressions used in assertions are programmatically definitive. There is no maybe state for a Boolean value. Maybe creeps in when a developer ponders, "Maybe I should use an assertion here, but I don't want to be too restrictive." If you expect a condition to be true at a certain point of program execution, then assert that condition. Assertions clearly and definitively document program expectation for normal execution. The clearer, the better.
Convention holds that you should use Java's exception-handling facility to ensure the validity of input arguments to a public method. Conventions are established for many reasons, particularly for necessity. Through the first three major Java releases, exceptions provided the only language mechanism for dealing with illegal arguments passed to a method. With the addition of the assertion facility, however, this convention should be revisited and scrapped.
To argue the issue, I'll use the jargon of Design by Contract (DBC). There are many excellent resources on DBC, so I won't attempt to explain the concepts in detail. (A good place to start is "Applying 'Design by Contract'" (IEEE Computer, October 1992) by Bertrand Meyer, who introduced DBC (no URL available for this article).)
Central to DBC is the notion of a contract between client and supplier. The interaction between software classes is viewed as analogous to a contract between two legal entities, each of which assumes specific responsibilities in exchange for certain expectations. For example, I might contract with a painting service to paint my house. The service assumes the responsibility to paint the house, and I assume the responsibility to pay for the service. I expect to have my house painted, and the painting service expects to be paid. There is a clear connection between expectation and responsibility.