The important thing to note when using your own error handler is that it will bypass the error_reporting setting and pass all errors (notices, warnings, etc.) to your error handler. You can set a second argument on set_error_handler() to define which error types you want to receive, or access the current setting using ... = error_reporting() inside the error handler.

Suppressing the warning

Another possibility is to suppress the call with the @ operator and check the return value of dns_get_record() afterwards. But I'd advise against this as errors/warnings are triggered to be handled, not to be suppressed.

is it advisable to set my own error handler right before the function call, then restore_error_handler when the error checking is done?
–
user121196Aug 6 '09 at 22:19

1

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 ?
–
user121196Aug 6 '09 at 22:23

1

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 GerberAug 6 '09 at 23:01

+1 for the avoidance of using @ to suppress errors. E_WARNING is actually a non-fatal error. In general you should always try to handle errors appropriately. If your application requires the usage of set_error_handler then do so. It is usually advisable to log errors and disable the display of them in a production environment. Upon checking the logs you can see where to make changes in your development environment. Too many instances where I've seen @fopen/@unlink and wonder why the developer didn't perform checks to avoid the errors or handle the error using set_error_handler.
–
fyryeJan 21 '14 at 17:36

Be careful with the @ operator - while it suppresses warnings it also suppresses fatal errors. I spent a lot of time debugging a problem in a system where someone had written @mysql_query( '...' ) and the problem was that mysql support was not loaded into PHP and it threw a silent fatal error. It will be safe for those things that are part of the PHP core but please use it with care.

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.

I wanted to try/catch a warning, but at the same time keep the usual warning/error logging (e.g. in /var/log/apache2/error.log); for which the handler has to return false. However, since the "throw new..." statement basically interrupts the execution, one then has to do the "wrap in function" trick, also discussed in:

EDIT: after closer inspection, it turns out it doesn't work: the "return false && throwErrorException ..." will, basically, not throw the exception, and just log in the error log; removing the "false &&" part, as in "return throwErrorException ...", will make the exception throwing work, but will then not log in the error_log... I'd still keep this posted, though, as I haven't seen this behavior documented elsewhere.