-
Notifications
You must be signed in to change notification settings - Fork 35.8k
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
log: Nuke error(...) #29236
log: Nuke error(...) #29236
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Big Concept ACK. |
fa3b64f
to
fa6d7ed
Compare
fa6d7ed
to
fa7658b
Compare
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.
Approach ACK fa7658b
I too have been confused by return error
many a times.
@@ -60,7 +61,8 @@ bool SerializeFileDB(const std::string& prefix, const fs::path& path, const Data | |||
if (fileout.IsNull()) { | |||
fileout.fclose(); | |||
remove(pathTmp); | |||
return error("%s: Failed to open file %s", __func__, fs::PathToString(pathTmp)); | |||
LogError("%s: Failed to open file %s\n", __func__, fs::PathToString(pathTmp)); |
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.
nit: it seems the return value from SerializeFileDB
is never used to actually shut down the node. In the case of failing to open file, I think LogError
is appropriate because that probably should lead to a shutdown. In the case of "Failed to flush file", I think a LogWarning
could be more appropriate.
I think it's best to leave the PR as is to make progress, bikeshedding over warning vs error categories doesn't have a huge amount of benefit here. Just leaving this comment for visibility.
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.
Yeah, but "error" is still applicable within the addrdb functions, as they can not continue and must return. So I think, ideally they'd return Result<void>
, and the caller could downgrade the error to a warning and log it? Happy to review such a change, if someone creates it.
fa7658b
to
fa1d4f0
Compare
Concept ACK fa1d4f0.
Any conceivable downsides to removing it? |
I can't see one, apart from the change consuming time to review 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.
utACK fa1d4f0.
@@ -358,14 +359,17 @@ bool Socks5(const std::string& strDest, uint16_t port, const ProxyCredentials* a | |||
return false; |
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.
nit - Noticed this when reviewing the changes. Since we're already changing the file - should Line 357/358 be a LogError
not a LogPrintf
?
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.
If there are changes to other log lines, I'd say it would be best to do them in a separate pull request. The goal here is to be as close to a refactor as possible.
} | ||
} | ||
if (pchRet2[0] != SOCKSVersion::SOCKS5) { | ||
return error("Proxy failed to accept request"); | ||
LogError("Proxy failed to accept request\n"); | ||
return false; | ||
} | ||
if (pchRet2[1] != SOCKS5Reply::SUCCEEDED) { | ||
// Failures to connect to a peer that are not proxy errors | ||
LogPrintf("Socks5() connect to %s:%d failed: %s\n", strDest, port, Socks5ErrorString(pchRet2[1])); |
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.
nit - Also noticed this when reviewing the changes. Since we're already changing the file - should Line 413/422 be a LogError
not a LogPrintf
?
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.
Why? This line is a failure to connect to a peer and the above are proxy errors. So keeping this as-is makes most sense. In any case, if there is a reason to change something unrelated in other lines, a separate pull request would be ideal.
Tested ACK fa1d4f0.
Passed
|
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.
ACK fa1d4f0
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.
Code review ACK fa1d4f0
This is a nice improvement, and it actually doesn't change many lines of code, so I don't think we should be worried about conflicts if we want to make more improvements later, like changing log levels, or adding categories, or switching to util::Result.
One thing I think we probably should revisit after this is the interaction with -logsourcelocations
, since it seems like a lot (maybe most?) of the new LogError calls are manually adding "%s: ", __func__ prefixes to the log, which shows the function name in a different format than -logsourcelocations
, and also includes the function name twice if -logsourcelocations
is enabled. A way to improve this might be to add an option to LogError to make it log the source location even if -logsourcelocations
is not turned on. Or maybe it would be better if the error messages were more descriptive and didn't rely on the function names to provide context.
utACK fa1d4f0 There is still a reference to |
I think this is RFM? |
It conflicts with something that will be merged after branch-off. |
This is required for the next commit to be correct.
This is needed for the next commit. -BEGIN VERIFY SCRIPT- # Separate sed invocations to replace one-line, and two-line error(...) calls sed -i --regexp-extended 's!( +)return (error\(.*\);)!\1\2\n\1return false;!g' $( git grep -l 'return error(' ) sed -i --null-data --regexp-extended 's!( +)return (error\([^\n]*\n[^\n]*\);)!\1\2\n\1return false;!g' $( git grep -l 'return error(' ) -END VERIFY SCRIPT-
This is needed for the next commit to compile.
This fixes the log output when -logsourcelocations is used. Also, instead of 'ERROR:', the log will now say '[error]', like other errors logged with LogError. -BEGIN VERIFY SCRIPT- sed -i --regexp-extended 's! error\("([^"]+)"! LogError("\1\\n"!g' $( git grep -l ' error(' ./src/ ) -END VERIFY SCRIPT-
fa1d4f0
to
fa39151
Compare
rebased. Should be trivial to re-ACK, as no lines touched by this are affected (only one tangent line) |
re-utACK fa39151 Based on |
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.
Code review ACK fa39151. Just rebase since last review
d0e6564 log: Remove error() reference (Fabian Jahr) Pull request description: Mini-followup to #29236 that was just merged. Removes a reference to `error()` that was missed in a comment. ACKs for top commit: ryanofsky: Code review ACK d0e6564. Just dropped LogPrintf reference since last review stickies-v: ACK d0e6564 Empact: ACK d0e6564 Tree-SHA512: 8abe4895951013c2ceca9a57743aacabaf8af831d07eee9ae8372c121c16e88b7226f0e537200c3464792e19ac7e03b57ba0be31f43add8802753972b0aefc48
error(...)
has many issues:return error(...)
, implying that it has a "fancy" type, creating confusion withutil::Result/Error
-logsourcelocations
does not work with it, because it will pretend the error happened inside oflogging.h
ERROR:
, as opposed to[error]
, like for other errors logged withLogError
.Fix all issues by removing it.