It will check the document and point to the assertion point of failure brought down by nils or bad values in the code.
Judicious use of FailFast assertions to check the assumptions can ensures that the program will end as soon as a contract violation is detected.
One of the primary goals of FailFast is to make assumption-checking declarative. Assumption checking should be simple and concise so that it can get to the meat of a method without getting blocked down in verifications.
At the same time, FailFast is lightweight. It is not a metaprogrammed Design-by-Contract DSL. It is a simple set of shorthand methods for validating values.
It is not the intent of FailFast to have specialized assertions for every eventuality.
Rather, it seeks to cover a few common cases where there is a potential for significantly increased clarity and declarativeness.
Here are some key features of "FailFast":
· Fully spec’d/tested.
· In most cases assertions return their last argument. This makes it easy to check values inline. For instance: assert_exists(obj).foo()
· Most assertions can take a block where a further boolean check can be performed. For instance, use assert_exists(x) { x.predicate? } to check first that x is not nil, and then that it satisfies a predicate.
· AssertionFailure derives directly from Exception so that it will never be silently eaten by no-argument catch statements.
Find us on Google+
