-
Notifications
You must be signed in to change notification settings - Fork 274
Fix/redirect exception handler output #3921
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
Fix/redirect exception handler output #3921
Conversation
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.
Generally looks good to me, but I'd like to understand why we cannot use message handlers here.
@@ -35,16 +35,23 @@ void parse_options_baset::help() | |||
|
|||
void parse_options_baset::usage_error() | |||
{ | |||
std::cerr << "Usage error!\n\n"; | |||
error_message("Usage error!\n"); |
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 is passing a message handler to parse_options_baset
not an option, so that this would be something like log.error() << "Usage error!\n" << messaget::eom;
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.
Various programs inherit from both messaget
and parse_option_baset
. If you would prefer things like program_parse_options::program_parse_options : messaget(), parse_option_baset(*this) { ...
then I can do it that way.
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.
Even though I strongly disagree with the inheritance done elsewhere, as far as parse_options_baset
is concerned that's what I was thinking, yes. So I'd add a message_handlert &message_handler;
member to parse_options_baset
and then, on demand, create a messaget log(message_handler);
. That way we can get away with a forward declaration of class message_handlert
in parse_options.h
, don't actually create unnecessary objects that we should not need under normal circumstances, and still do the output in the way desired and controlled by the caller.
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.
Sounds good. I'll have a go and will open a new 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.
Hmm, I thought the difference should be fairly small?
This allows a class that inherits from parse_options_baset to override the standard direction for error messages from exception handlers so that they can be correctly formatted in JSON, XML, etc.
This means that exceptions, invariant failures, etc. will be given in the appropriate format.
These should check that exception messages are output wrapped in JSON rather than just dumped on std::cerr.
821bc8e
to
9816337
Compare
Closed in favour of #3951 . |
As requested by @kroening this builds on #3897 to allow the exception handlers output to be wrapped appropriately. This enables the two test cases given in #3902 and should get us closer to not having things dumped on std:cerr when running in JSON or XML UI modes.