|
|
|
| Perl-Sensitive Sunglasses | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
As you know, an assertion is a statement evaluating to a boolean (ie. true/false) value; Assertion predicates are typically used to check the state of code blocks at entry (precondition), during execution (invariants) and at exit (postcondition), thus verifying runtime compliance with a specified design contract (pre/post) and with assumptions of program state (invariants) for the implementation of an algorithm.
Typically an assertion failure will throw an exception with an error message and a context/stack trace, thus facilitating debugging and error fixing. In Perl we have several mechanisms for implementing assertions, ranging from the simple and general <predicate> or die "Can't ...: $!"; over the eval { <predicate>; }; die $@ if $@; to the use of specialized Smart comments (require, assert, ensure, insist etc.), Test predicates (ok, is, isnt, like, unlike, cmp_ok, can_ok etc.), -- and a range of other CPAN Assert modules. Programming with assertions for debug scaffolding and unit testing has long been considered a Good Thing for ensuring compliance of program runtime behaviour viz application design and specs; (-- for an interesting historical record, see: Tony Hoare Assertions: a personal perspective). This is basically how i have been using assertions in my own programming in the past, -- though not as rigoristic as promoted by the Design by contract methodology.Now I'm interested in hearing to what extent and with what means you fellow monks are using assertions in your Perl programming? My renewed interest in the use of assertions was sparked by a recent article in DDJ CodeTalk, where Walter Bright raised the question of using 'resilient' assertions in high reliability production code, -- rightly questioned, I think, by the commenters of the article, -- but food for thought.Any comments on this approach, based on your own experiences? Best regards Allan Dystrup update
In the above Assertions... reference Tony Hoare writes :
The primary role of an assertion today is as a test oracle, defining the circumstances under which a program under test is considered to fail. ... many teams leave the assertions in ship code to generate an exception when false; to continue execution in such an unexpected and untested circumstance would run a grave risk of crash. So instead, the handler for the exception makes a recovery that is sensible to the customer in the environment of use. That nicely wraps up (I think) the discussion of what i've called 'resilient' assertions in production code (cf. DDJ CodeTalk); What's perhaps more interesting in Hoare's paper is his aim of using assertions to express program intention/semantics thus allowing automatic verification/proof. As he writes : ...the axiomatic method has been explicitly used to guide the design of languages like Euclid and Eiffel 20, 21. These languages were prepared to accept the restrictions on the generality of expression that are necessary to make the axioms consistent with efficient program execution. ...there are now strong signs that the actual quality of the language is beginning to matter. ...One day, I expect the new programming language designer will learn how to use assertional methods as a design tool, to evaluate and refine the objectively evaluated quality of familiar language features, as well as averting the risks involved in the introduction of new features. I was wondering which (if any) effect this kind of conderation has (had) on the development of Perl6, -- taking into account the special nature of dynamic languages and the explicit design goal of flexibility/TimToadyNess of Perl ? In reply to Your use of assertions in Perl ? by ady
|
|