You should probably try to get rid of the warning completely, but if that's not possible, you can prepend the call with @ (i.e. @dns_get_record(...)) and then use any information you can get to figure out if the warning happened or not.
+2
A:
Rusky
2009-08-06 21:53:51
+2
A:
One possibility is to set your own error handler before the call and restore the previous error handler later with restore_error_handler()
. Zend Framework does this at several locations. BTW there's was some discussion lately on the PHP newsgroup about replacing PHP errors with exceptions natively.
Another possibility is to suppress the call with the @ operator and check the return value of dns_get_record()
afterwards.
sidenote
You can use set_error_handler()
and the ErrorException
class to turn all php errors into exceptions.
function handleError($errno, $errstr, $errfile, $errline, array $errcontext)
{
// error was suppressed with the @-operator
if (0 === error_reporting()) {
return false;
}
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler('handleError');
try {
dns_get_record();
}
catch (ErrorException $e) {
// ...
}
Philippe Gerber
2009-08-06 21:55:39
is it advisable to set my own error handler right before the function call, then restore_error_handler when the error checking is done?
2009-08-06 22:19:44
will this be thread safe if there are many concurrent requests, and each request does 1.set_error_handler(). 2.doit 3.restore_error_handler ?
2009-08-06 22:23:02
1. if this is good practice? I really don't know. but if the dudes from Zend use this method, it can't really be that bad. 2. each request is self-contained, so there wont be any problem.
Philippe Gerber
2009-08-06 23:01:01
A:
If dns_get_record()
fails, it should return FALSE
, so you can suppress the warning with @
and then check the return value.
Amber
2009-08-06 21:58:19