-
-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify error handling for dns_get_record()
#378
base: 4.x
Are you sure you want to change the base?
Conversation
2978d4c
to
52969e9
Compare
We have the same issue on running test with fake domain eg:
|
Hi @aivchen thanks for your PR. I have fixed the checks so please update with the latest code to have the checks pass. |
792fb31
to
f0df316
Compare
Hi @egulias I've rebased my branch but the build failed again. Seems you have empty CODACY_PROJECT_TOKEN in github secrets. |
That error is driving me nuts. The secret has vale and is correct. In fact it has been working. |
Secrets can't be used in forked repos:) |
Thanks @aivchen didn't know that (I haven't spent too much time with gh actions). |
} finally { | ||
restore_error_handler(); | ||
} | ||
$result = @dns_get_record($host, $type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I understand set_error_handler
is possibly interfering with the broader project that might itself be setting that same error handler. Now, the function is releasing / restoring the handler at the end.
The aim is to catch these errors.
Suppressing them defeats the purpose. So, what do you think if we find a way for this to be optional with the suppressed option being the default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I understand set_error_handler is possibly interfering with the broader project that might itself be setting that same error handler.
Not really. In the set_error_handler
function we throw an exception which we catch directly in the same file. The old code with comments.
set_error_handler(
static function (int $errorLevel, string $errorMessage): never {
// Here we throw an exception if dns_get_record function failed.
throw new \RuntimeException("Unable to get DNS record for the host: $errorMessage");
}
);
try {
// Get all MX, A and AAAA DNS records for host
return new DNSRecords(dns_get_record($host, $type));
} catch (\RuntimeException $exception) {
return new DNSRecords([], true); // And here we catch the exception thrown in set_error_handler.
} finally {
restore_error_handler();
}
Therefore, my changes do not introduce any changes in logic - just a shorter entry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I didn't see that we pass true
param in the catch block. Let me fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the PHP bug (https://bugs.php.net/bug.php?id=73149 ) being addressed by the workaround and it is still happening.
In short, the bug allows an unexpected error to bypass the error suppression (@
) which being un-handled then breaks the execution not only of the library but of the system using it. Which would then require our users to wrap, just in case, the call in a try/catch statement.
That's something I try to avoid the users of the library to do.
So we cannot simplify the code unless the bug is fixed or a different approach is found.
f0df316
to
9e0fbfc
Compare
This comment was marked as outdated.
This comment was marked as outdated.
9e0fbfc
to
582d3cf
Compare
No description provided.