Delicious Bookmark this on Delicious Share on Facebook SlashdotSlashdot It! Digg! Digg



PHP : Function Reference : PHP Options&Information : assert

assert

Checks if assertion is FALSE (PHP 4, PHP 5)
bool assert ( mixed assertion )

Example 1831. Handle a failed assertion with a custom handler

<?php
// Active assert and make it quiet
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);

// Create a handler function
function my_assert_handler($file, $line, $code)
{
   echo
"<hr>Assertion Failed:
       File '$file'<br />
       Line '$line'<br />
       Code '$code'<br /><hr />"
;
}

// Set up the callback
assert_options(ASSERT_CALLBACK, 'my_assert_handler');

// Make an assertion that should fail
assert('mysql_query("")');
?>

Code Examples / Notes » assert

krzysztof 'chanibal' bociurko

Note that func_get_args() should be used carefully and never in a string! For example:
<?php
function asserted_normal($a, $b) {
assert(var_dump(func_get_args()));
}
function asserted_string($a, $b) {
assert('var_dump(func_get_args())');
}
?>
<?php asserted_normal(1,2) ?> prints
array(2) {
 [0]=>
 int(1)
 [1]=>
 int(2)
}
but <?php asserted_string(3,4) ?> prints
array(1) {
 [0]=>
 string(25) "var_dump(func_get_args())"
}
This is because of that the string passed to assert() is being evaled inside assert, and not your function. Also, note that this works correctly, because of the eval scope:
<?php
function asserted_evaled_string($a, $b) {
assert(eval('var_dump(func_get_args())'));
}
asserted_evaled_string(5,6);
?>
array(2) {
 [0]=>
 int(5)
 [1]=>
 int(6)
}
(oh, and for simplicity's sake the evaled code doesn't return true, so  don't worry that it fails assertion...)


matthew,

Much of the value of assertions comes from the assumption that you can do performance intensive checking for debugging that will not affect the code in production. Breaking the assumption that assertions will not be routinely enabled in production prohibits this usage and is counterproductive.

gk

If you expect your code to be able to work well with other code, then you should not make any assumptions about the current state of assert_options() flags, prior to calling assert(): other code may disable ASSERT_ACTIVE, without you knowing it - this would render assert() useless!
To avoid this, ALWAYS set assert_options() IMMEDIATELY before calling assert(), per the C++ paradigm for assertion usage:
In one C++ source file, you can define and undefine NDEBUG multiple times, each time followed by #include <cassert>, to enable or disable the assert macro multiple times in the same source file.
Here is how I workaround this issue in my PHP code:
//////////////////////////////////////////////////////////////////////
/// phpxAssertHandler_f
//////////////////////////////////////////////////////////////////////
/**
* @desc     Handler which also sets up assert options if not being called as handler
Always fatal when assertion fails
Always make sure assertion is enabled
Cannot depend on other code not using assert or using its own assert handler!
USAGE:
// customize error level of assertion (php assert_options() only allows E_WARNING or nothing at all):
phpxAssertHandler_f(E_USER_NOTICE);
// control assertion active state: not dependent on anything another piece of code might do with ASSERT_ACTIVE
$GLOBALS['MY_ASSERT_ACTIVE']=false;
phpxAssertHandler_f(E_USER_NOTICE,$GLOBALS['MY_ASSERT_ACTIVE']);
// use alternate assertion callback function:
// NOTE: pass null as custom options parameter to use default options
// NOTE: pass no values for assert options parameter array elements to use default options
$GLOBALS['MY_ASSERT_ACTIVE']=false;
$GLOBALS['MY_ASSERT_CALLBACK']='myAssertCallback';
phpxAssertHandler_f(
null,
array(
0=>$GLOBALS['MY_ASSERT_ACTIVE'],
3=>$GLOBALS['MY_ASSERT_CALLBACK'],
)
);

* @param   mixed = file or options
* @param   line
* @param   code
* @return   void
*/
function phpxAssertHandler_f($file_or_custom_options=null, $line_or_assert_options=null, $code=null){
static $custom_options;
$debug = false;
if (is_null($code)){
// set default assert_options
$assert_options[]=1;//ASSERT_ACTIVE
$assert_options[]=0;//ASSERT_WARNING -
$assert_options[]=0;//ASSERT_QUIET_EVAL
$assert_options[]=__FUNCTION__;//ASSERT_CALLBACK
// set default custom_options
$custom_options[]=E_USER_ERROR;// error level
if (!is_null($line_or_assert_options)){
// assert_options are passed in
if (!is_array($line_or_assert_options)){
$line_or_assert_options=array($line_or_assert_options);
}
foreach ($line_or_assert_options as $i=>$assert_option){
if ($assert_option===true) $assert_option=1;
if ($assert_option===false) $assert_option=0;
$assert_options[$i]=$assert_option;
if($debug) echo ("assert_options[$i]=$assert_option\n");
}
}
if (!is_null($file_or_custom_options)){
// custom_options are passed in
if (!is_array($file_or_custom_options)){
$file_or_custom_options=array($file_or_custom_options);
}
foreach ($file_or_custom_options as $i=>$custom_option){
if ($custom_option===true) $custom_option=1;
if ($custom_option===false) $custom_option=0;
$custom_options[$i]=$custom_option;
if($debug) echo ("custom_options[$i]=$custom_option\n");
}
}
// set assert options
@assert_options (ASSERT_ACTIVE, $assert_options[0]);
@assert_options (ASSERT_WARNING, $assert_options[1]);
@assert_options (ASSERT_QUIET_EVAL, $assert_options[2]);
@assert_options (ASSERT_CALLBACK, $assert_options[3]);
} else {
// we are acting as a callback function
$file = $file_or_custom_options;
$line = $line_or_assert_options;
    $msg="ASSERTION FAILED: $code";
    phpxErrorHandler_f ($custom_options[0],$msg,$file,$line);
}
}//phpxAssertHandler_f()


hodgman

I dont agree with gk at proliberty dot com's statements below.
If you are constantly enabling assertions before each assertion, then you are removing the functionality provided by being able to turn off assertions in the first place.
Assertions should only be enabled during testing/development, and then disabled once your code reaches a production stage.
This means you should either leave disabling/enabling assertions up to the INI file, or let the entry point of the script decide.
If you need an assertion to be there in the final copy of the code, then you are using the wrong tool. Assertions are a tool for debugging only.


tom russo

hodgman at ali dot com dot au said:
"Assertions should only be enabled during testing/development, and then disabled once your code reaches a production stage."
Assertions should _not_ be turned off in production code.  Although it's common to do so, turning off assertions in production is a bad practice.
If your production code fails an assert, YOU WANT TO KNOW ABOUT IT.  Asserts are a debugging tool, but you should not stop debugging your code just because it has gone into production.
Many people claim that removing asserts gives a performance benefit.  In modern programming languages this simply isn't true.  If you were doing an assert on something that is extremely slow/expensive to compute, you might consider turning that assert off.  But in practice this really isn't how asserts are used.
There's a good discussion of this issue in the book The Pragmatic Programmer.


mailaaron-mueller.de

Here is a simple demonstration of Design By Contract with PHP
<?php
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_BAIL, 1);
assert_options(ASSERT_CALLBACK, 'dcb_callback');
function dcb_callback($script, $line, $message) {
echo "<h1>Condition failed!</h1><br />
Script: <strong>$script</strong><br />
Line: <strong>$line</strong><br />
Condition: <br /><pre>$message</pre>";
}
// Parameters
$a = 5;
$b = 'Simple DCB with PHP';
// Pre-Condition
assert('
is_integer($a) &&
($a > 0) &&
($a < 20) &&

is_string($b) &&
(strlen($b) > 5);
');
// Function
function combine($a, $b) {
return "Kombined: " . $b . $a;
}
$result = combine($a, $b);
// Post-Condition
assert('
is_string($result) &&
(strlen($result) > 0);
');
// All right, the Function works fine
var_dump($result);
?>


nyk

Assertion is a useful debugging feature, but for building unit tests and automated regression tests you should seriously consider using the PHPtest in the PEAR archive (http://pear.php.net/package-info.php?pacid=38) that is based on the JUnit framework for Java. There is also another unit testing framework, also based on JUnit and also called PHPunit on SourceForge (http://sourceforge.net/projects/phpunit/). I believe it is an independent effort from that on PEAR.

thomas

Another very good unit testing framework is SimpleTest, which can be found at http://www.lastcraft.com/simple_test.php
It has very good documentation, support for mock objects and tools for automating testing of entire web sites.


Change Language


Follow Navioo On Twitter
assert_options
assert
dl
extension_loaded
get_cfg_var
get_current_user
get_defined_constants
get_extension_funcs
get_include_path
get_included_files
get_loaded_extensions
get_magic_quotes_gpc
get_magic_quotes_runtime
get_required_files
getenv
getlastmod
getmygid
getmyinode
getmypid
getmyuid
getopt
getrusage
ini_alter
ini_get_all
ini_get
ini_restore
ini_set
main
memory_get_peak_usage
memory_get_usage
php_ini_scanned_files
php_logo_guid
php_sapi_name
php_uname
phpcredits
phpinfo
phpversion
putenv
restore_include_path
set_include_path
set_magic_quotes_runtime
set_time_limit
sys_get_temp_dir
version_compare
zend_logo_guid
zend_thread_id
zend_version
eXTReMe Tracker