-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Cleanly report invalid [server] settings (RIPD-1562) #2305
Conversation
Jenkins Build SummaryBuilt from this commit Built at 20171220 - 19:38:23 Test Results
|
Codecov Report
@@ Coverage Diff @@
## develop #2305 +/- ##
==========================================
+ Coverage 70.23% 70.93% +0.7%
==========================================
Files 706 691 -15
Lines 61334 51391 -9943
==========================================
- Hits 43077 36456 -6621
+ Misses 18257 14935 -3322
Continue to review full report at Codecov.
|
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.
looks good to me. just a note that these errors are treated as warning by the rpcClient (rippled as client) and that means you get some other subsequent failure depending on the field that was missing or invalid.
src/ripple/app/main/Application.cpp
Outdated
} | ||
catch (std::exception const&) | ||
{ | ||
JLOG(m_journal.fatal()) << "Unable to setup server handler"; |
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.
It might be useful to log the exception message if one exists. Even if the current code is unlikely to produce one now, it might catch a new message in the future.
Just an idea- If the exception message was logged here, throws in to_Port
or populate
etc.. could include the message instead of logging and throwing which seems kinda kludgy.
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.
Good suggestions. I went with printing the message if one exists to keep a limited scope of this PR.
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.
👍
@@ -893,19 +893,19 @@ to_Port(ParsedPort const& parsed, std::ostream& log) | |||
|
|||
if (! parsed.ip) | |||
{ | |||
log << "Missing 'ip' in [" << p.name << "]\n"; | |||
log << "Missing 'ip' in [" << p.name << "]"; | |||
Throw<std::exception> (); |
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.
Food for thought: why not do something like:
Throwstd::runtime_exception("Missing 'ip' in [" + p.name + "]");
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.
@miguelportilla suggested a similar change.
I had gone down that route (along with eliminating the exceptions altogether), but it was starting to touch more code than I was comfortable with for this targeted change. I wasn't sure if some callers wanted to distinguish logging from exception handling.
In 0.90.0-b3 |
Ensure when standing up the server at startup, we catch any exceptions related to invalid
[server]
settings and cleanly report them before shutting down.