First; the way that the code in the article does it is evil. throw ex
will reset the call stack in the exception to the point where this throw statement is; losing the information about where the exception actually was created.
Second, if you just catch and re-throw like that, I see no added value, the code example above would be just as good (or, given the throw ex
bit, even better) without the try-catch.
However, there are cases where you might want to catch and rethrow an exception. Logging could be one of them:
try
{
// code that may throw exceptions
}
catch(Exception ex)
{
// add error logging here
throw;
}
Set and restore error handler
One possibility is to set your own error handler before the call and restore the previous error handler later with restore_error_handler()
.
set_error_handler(function() { /* ignore errors */ });
dns_get_record();
restore_error_handler();
You could build on this idea and write a re-usable error handler that logs the errors for you.
set_error_handler([$logger, 'onSilencedError']);
dns_get_record();
restore_error_handler();
Turning errors into exceptions
You can use set_error_handler()
and the ErrorException
class to turn all php errors into exceptions.
set_error_handler(function($errno, $errstr, $errfile, $errline) {
// error was suppressed with the @-operator
if (0 === error_reporting()) {
return false;
}
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
});
try {
dns_get_record();
} catch (ErrorException $e) {
// ...
}
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.
Best Answer
Here is a blog post that covers it at a highish level: Exception handling in SQLCLR
This seems to imply that it will just work.