/**
* Assertion utility class that assists in validating arguments.
* Useful for identifying programmer errors early and clearly at runtime.
*
*For example, if the contract of a public method states it does not
* allow {@code null} arguments, Assert can be used to validate that
* contract. Doing this clearly indicates a contract violation when it
* occurs and protects the class's invariants.
*
*Typically used to validate method arguments rather than configuration
* properties, to check for cases that are usually programmer errors rather than
* configuration errors. In contrast to config initialization code, there is
* usally no point in falling back to defaults in such methods.
*
*This class is similar to JUnit's assertion library. If an argument value is
* deemed invalid, an {@link IllegalArgumentException} is thrown (typically).
* For example:
*
* <pre class="code">
* Assert.notNull(clazz, "The class must not be null");
* Assert.isTrue(i > 0, "The value must be greater than zero");</pre>
*
* Mainly for internal use within the framework; consider Jakarta's Commons Lang
* >= 2.0 for a more comprehensive suite of assertion utilities.
*
* @author Keith Donald
* @author Juergen Hoeller
* @author Colin Sampaleanu
* @author Rob Harrop
* @since 1.1.2
*/
Did authors write this entire statement? If true. Looks like it is a tougher job than writing a class alone.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Most of that stuff was written by the developers, since, hey, it's the 21st Century so why get a professional specialist to do something when you can just dump one more task on the primary developer? Then again, I've worked with documentation specialists who couldn't seem to be persuaded that the documents needed to track the software and not simply exist for their own sakes.
I was into "literate programming" even before Knuth coined the term or Java was developed. In fact, I'd developed an AWK script that auto-generated Windows Help files for code based on specially marked comments, not only in the headers (JavaDoc style), but in the function body (usually step-by-step explanations of what was being done).
One of the best incentives to use Javadoc markup is that many modern IDEs can look aside and provide "hover help" when you do a trial type-in of a method or object reference. So a good documentation header can make coding a lot easier.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |