.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.40) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "Carp::Assert 3pm" .TH Carp::Assert 3pm "2020-12-28" "perl v5.32.0" "User Contributed Perl Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" Carp::Assert \- executable comments .SH "SYNOPSIS" .IX Header "SYNOPSIS" .Vb 2 \& # Assertions are on. \& use Carp::Assert; \& \& $next_sunrise_time = sunrise(); \& \& # Assert that the sun must rise in the next 24 hours. \& assert(($next_sunrise_time \- time) < 24*60*60) if DEBUG; \& \& # Assert that your customer\*(Aqs primary credit card is active \& affirm { \& my @cards = @{$customer\->credit_cards}; \& $cards[0]\->is_active; \& }; \& \& \& # Assertions are off. \& no Carp::Assert; \& \& $next_pres = divine_next_president(); \& \& # Assert that if you predict Dan Quayle will be the next president \& # your crystal ball might need some polishing. However, since \& # assertions are off, IT COULD HAPPEN! \& shouldnt($next_pres, \*(AqDan Quayle\*(Aq) if DEBUG; .Ve .SH "DESCRIPTION" .IX Header "DESCRIPTION" .Vb 3 \& "We are ready for any unforseen event that may or may not \& occur." \& \- Dan Quayle .Ve .PP Carp::Assert is intended for a purpose like the \s-1ANSI C\s0 library assert.h . If you're already familiar with assert.h, then you can probably skip this and go straight to the \s-1FUNCTIONS\s0 section. .PP Assertions are the explicit expressions of your assumptions about the reality your program is expected to deal with, and a declaration of those which it is not. They are used to prevent your program from blissfully processing garbage inputs (garbage in, garbage out becomes garbage in, error out) and to tell you when you've produced garbage output. (If I was going to be a cynic about Perl and the user nature, I'd say there are no user inputs but garbage, and Perl produces nothing but...) .PP An assertion is used to prevent the impossible from being asked of your code, or at least tell you when it does. For example: .PP .Vb 3 \& # Take the square root of a number. \& sub my_sqrt { \& my($num) = shift; \& \& # the square root of a negative number is imaginary. \& assert($num >= 0); \& \& return sqrt $num; \& } .Ve .PP The assertion will warn you if a negative number was handed to your subroutine, a reality the routine has no intention of dealing with. .PP An assertion should also be used as something of a reality check, to make sure what your code just did really did happen: .PP .Vb 3 \& open(FILE, $filename) || die $!; \& @stuff = ; \& @stuff = do_something(@stuff); \& \& # I should have some stuff. \& assert(@stuff > 0); .Ve .PP The assertion makes sure you have some \f(CW@stuff\fR at the end. Maybe the file was empty, maybe \fBdo_something()\fR returned an empty list... either way, the \fBassert()\fR will give you a clue as to where the problem lies, rather than 50 lines down at when you wonder why your program isn't printing anything. .PP Since assertions are designed for debugging and will remove themelves from production code, your assertions should be carefully crafted so as to not have any side-effects, change any variables, or otherwise have any effect on your program. Here is an example of a bad assertation: .PP .Vb 1 \& assert($error = 1 if $king ne \*(AqHenry\*(Aq); # Bad! .Ve .PP It sets an error flag which may then be used somewhere else in your program. When you shut off your assertions with the \f(CW$DEBUG\fR flag, \&\f(CW$error\fR will no longer be set. .PP Here's another example of \fBbad\fR use: .PP .Vb 1 \& assert($next_pres ne \*(AqDan Quayle\*(Aq or goto Canada); # Bad! .Ve .PP This assertion has the side effect of moving to Canada should it fail. This is a very bad assertion since error handling should not be placed in an assertion, nor should it have side-effects. .PP In short, an assertion is an executable comment. For instance, instead of writing this .PP .Vb 2 \& # $life ends with a \*(Aq!\*(Aq \& $life = begin_life(); .Ve .PP you'd replace the comment with an assertion which \fBenforces\fR the comment. .PP .Vb 2 \& $life = begin_life(); \& assert( $life =~ /!$/ ); .Ve .SH "FUNCTIONS" .IX Header "FUNCTIONS" .IP "\fBassert\fR" 4 .IX Item "assert" .Vb 2 \& assert(EXPR) if DEBUG; \& assert(EXPR, $name) if DEBUG; .Ve .Sp assert's functionality is effected by compile time value of the \s-1DEBUG\s0 constant, controlled by saying \f(CW\*(C`use Carp::Assert\*(C'\fR or \f(CW\*(C`no Carp::Assert\*(C'\fR. In the former case, assert will function as below. Otherwise, the assert function will compile itself out of the program. See \*(L"Debugging vs Production\*(R" for details. .Sp Give assert an expression, assert will \fBCarp::confess()\fR if that expression is false, otherwise it does nothing. (\s-1DO NOT\s0 use the return value of assert for anything, I mean it... really!). .Sp The error from assert will look something like this: .Sp .Vb 3 \& Assertion failed! \& Carp::Assert::assert(0) called at prog line 23 \& main::foo called at prog line 50 .Ve .Sp Indicating that in the file \*(L"prog\*(R" an assert failed inside the function \fBmain::foo()\fR on line 23 and that \fBfoo()\fR was in turn called from line 50 in the same file. .Sp If given a \f(CW$name\fR, \fBassert()\fR will incorporate this into your error message, giving users something of a better idea what's going on. .Sp .Vb 2 \& assert( Dogs\->isa(\*(AqPeople\*(Aq), \*(AqDogs are people, too!\*(Aq ) if DEBUG; \& # Result \- "Assertion (Dogs are people, too!) failed!" .Ve .IP "\fBaffirm\fR" 4 .IX Item "affirm" .Vb 2 \& affirm BLOCK if DEBUG; \& affirm BLOCK $name if DEBUG; .Ve .Sp Very similar to \fBassert()\fR, but instead of taking just a simple expression it takes an entire block of code and evaluates it to make sure its true. This can allow more complicated assertions than \&\fBassert()\fR can without letting the debugging code leak out into production and without having to smash together several statements into one. .Sp .Vb 5 \& affirm { \& my $customer = Customer\->new($customerid); \& my @cards = $customer\->credit_cards; \& grep { $_\->is_active } @cards; \& } "Our customer has an active credit card"; .Ve .Sp \&\fBaffirm()\fR also has the nice side effect that if you forgot the \f(CW\*(C`if DEBUG\*(C'\fR suffix its arguments will not be evaluated at all. This can be nice if you stick \fBaffirm()\fRs with expensive checks into hot loops and other time-sensitive parts of your program. .Sp If the \f(CW$name\fR is left off and your Perl version is 5.6 or higher the \&\fBaffirm()\fR diagnostics will include the code begin affirmed. .IP "\fBshould\fR" 4 .IX Item "should" .PD 0 .IP "\fBshouldnt\fR" 4 .IX Item "shouldnt" .PD .Vb 2 \& should ($this, $shouldbe) if DEBUG; \& shouldnt($this, $shouldntbe) if DEBUG; .Ve .Sp Similar to \fBassert()\fR, it is specially for simple \*(L"this should be that\*(R" or \*(L"this should be anything but that\*(R" style of assertions. .Sp Due to Perl's lack of a good macro system, \fBassert()\fR can only report where something failed, but it can't report \fIwhat\fR failed or \fIhow\fR. \&\fBshould()\fR and \fBshouldnt()\fR can produce more informative error messages: .Sp .Vb 3 \& Assertion (\*(Aqthis\*(Aq should be \*(Aqthat\*(Aq!) failed! \& Carp::Assert::should(\*(Aqthis\*(Aq, \*(Aqthat\*(Aq) called at moof line 29 \& main::foo() called at moof line 58 .Ve .Sp So this: .Sp .Vb 1 \& should($this, $that) if DEBUG; .Ve .Sp is similar to this: .Sp .Vb 1 \& assert($this eq $that) if DEBUG; .Ve .Sp except for the better error message. .Sp Currently, \fBshould()\fR and \fBshouldnt()\fR can only do simple eq and ne tests (respectively). Future versions may allow regexes. .SH "Debugging vs Production" .IX Header "Debugging vs Production" Because assertions are extra code and because it is sometimes necessary to place them in 'hot' portions of your code where speed is paramount, Carp::Assert provides the option to remove its \fBassert()\fR calls from your program. .PP So, we provide a way to force Perl to inline the switched off \fBassert()\fR routine, thereby removing almost all performance impact on your production code. .PP .Vb 2 \& no Carp::Assert; # assertions are off. \& assert(1==1) if DEBUG; .Ve .PP \&\s-1DEBUG\s0 is a constant set to 0. Adding the 'if \s-1DEBUG\s0' condition on your \&\fBassert()\fR call gives perl the cue to go ahead and remove \fBassert()\fR call from your program entirely, since the if conditional will always be false. .PP .Vb 4 \& # With C the assert() has no impact. \& for (1..100) { \& assert( do_some_really_time_consuming_check ) if DEBUG; \& } .Ve .PP If \f(CW\*(C`if DEBUG\*(C'\fR gets too annoying, you can always use \fBaffirm()\fR. .PP .Vb 4 \& # Once again, affirm() has (almost) no impact with C \& for (1..100) { \& affirm { do_some_really_time_consuming_check }; \& } .Ve .PP Another way to switch off all asserts, system wide, is to define the \&\s-1NDEBUG\s0 or the \s-1PERL_NDEBUG\s0 environment variable. .PP You can safely leave out the \*(L"if \s-1DEBUG\*(R"\s0 part, but then your \fBassert()\fR function will always execute (and its arguments evaluated and time spent). To get around this, use \fBaffirm()\fR. You still have the overhead of calling a function but at least its arguments will not be evaluated. .SH "Differences from ANSI C" .IX Header "Differences from ANSI C" \&\fBassert()\fR is intended to act like the function from \s-1ANSI C\s0 fame. Unfortunately, due to Perl's lack of macros or strong inlining, it's not nearly as unobtrusive. .PP Well, the obvious one is the \*(L"if \s-1DEBUG\*(R"\s0 part. This is cleanest way I could think of to cause each \fBassert()\fR call and its arguments to be removed from the program at compile-time, like the \s-1ANSI C\s0 macro does. .PP Also, this version of assert does not report the statement which failed, just the line number and call frame via Carp::confess. You can't do \f(CW\*(C`assert(\*(Aq$a == $b\*(Aq)\*(C'\fR because \f(CW$a\fR and \f(CW$b\fR will probably be lexical, and thus unavailable to \fBassert()\fR. But with Perl, unlike C, you always have the source to look through, so the need isn't as great. .SH "EFFICIENCY" .IX Header "EFFICIENCY" With \f(CW\*(C`no Carp::Assert\*(C'\fR (or \s-1NDEBUG\s0) and using the \f(CW\*(C`if DEBUG\*(C'\fR suffixes on all your assertions, Carp::Assert has almost no impact on your production code. I say almost because it does still add some load-time to your code (I've tried to reduce this as much as possible). .PP If you forget the \f(CW\*(C`if DEBUG\*(C'\fR on an \f(CW\*(C`assert()\*(C'\fR, \f(CW\*(C`should()\*(C'\fR or \&\f(CW\*(C`shouldnt()\*(C'\fR, its arguments are still evaluated and thus will impact your code. You'll also have the extra overhead of calling a subroutine (even if that subroutine does nothing). .PP Forgetting the \f(CW\*(C`if DEBUG\*(C'\fR on an \f(CW\*(C`affirm()\*(C'\fR is not so bad. While you still have the overhead of calling a subroutine (one that does nothing) it will \fBnot\fR evaluate its code block and that can save a lot. .PP Try to remember the \fBif \s-1DEBUG\s0\fR. .SH "ENVIRONMENT" .IX Header "ENVIRONMENT" .IP "\s-1NDEBUG\s0" 4 .IX Item "NDEBUG" Defining \s-1NDEBUG\s0 switches off all assertions. It has the same effect as changing \*(L"use Carp::Assert\*(R" to \*(L"no Carp::Assert\*(R" but it effects all code. .IP "\s-1PERL_NDEBUG\s0" 4 .IX Item "PERL_NDEBUG" Same as \s-1NDEBUG\s0 and will override it. Its provided to give you something which won't conflict with any C programs you might be working on at the same time. .SH "BUGS, CAVETS and other MUSINGS" .IX Header "BUGS, CAVETS and other MUSINGS" .ie n .SS "Conflicts with ""POSIX.pm""" .el .SS "Conflicts with \f(CWPOSIX.pm\fP" .IX Subsection "Conflicts with POSIX.pm" The \f(CW\*(C`POSIX\*(C'\fR module exports an \f(CW\*(C`assert\*(C'\fR routine which will conflict with \f(CW\*(C`Carp::Assert\*(C'\fR if both are used in the same namespace. If you are using both together, prevent \f(CW\*(C`POSIX\*(C'\fR from exporting like so: .PP .Vb 2 \& use POSIX (); \& use Carp::Assert; .Ve .PP Since \f(CW\*(C`POSIX\*(C'\fR exports way too much, you should be using it like that anyway. .ie n .SS """affirm"" and $^S" .el .SS "\f(CWaffirm\fP and \f(CW$^S\fP" .IX Subsection "affirm and $^S" \&\fBaffirm()\fR mucks with the expression's caller and it is run in an eval so anything that checks $^S will be wrong. .ie n .SS """shouldn\*(Aqt""" .el .SS "\f(CWshouldn\*(Aqt\fP" .IX Subsection "shouldnt" Yes, there is a \f(CW\*(C`shouldn\*(Aqt\*(C'\fR routine. It mostly works, but you \fBmust\fR put the \f(CW\*(C`if DEBUG\*(C'\fR after it. .ie n .SS "missing ""if DEBUG""" .el .SS "missing \f(CWif DEBUG\fP" .IX Subsection "missing if DEBUG" It would be nice if we could warn about missing \f(CW\*(C`if DEBUG\*(C'\fR. .SH "SEE ALSO" .IX Header "SEE ALSO" assert.h \- the wikipedia page about \f(CW\*(C`assert.h\*(C'\fR. .PP Carp::Assert::More provides a set of convenience functions that are wrappers around \f(CW\*(C`Carp::Assert\*(C'\fR. .PP Sub::Assert provides support for subroutine pre\- and post-conditions. The documentation says it's slow. .PP PerlX::Assert provides compile-time assertions, which are usually optimised away at compile time. Currently part of the Moops distribution, but may get its own distribution sometime in 2014. .PP Devel::Assert also provides an \f(CW\*(C`assert\*(C'\fR function, for Perl >= 5.8.1. .PP assertions provides an assertion mechanism for Perl >= 5.9.0. .SH "REPOSITORY" .IX Header "REPOSITORY" .SH "COPYRIGHT" .IX Header "COPYRIGHT" Copyright 2001\-2007 by Michael G Schwern . .PP This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. .PP See \fIhttp://dev.perl.org/licenses/\fR .SH "AUTHOR" .IX Header "AUTHOR" Michael G Schwern