Skip to content

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

Conversation

martin-cs
Copy link
Collaborator

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

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.

Copy link
Collaborator

@tautschnig tautschnig left a 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");
Copy link
Collaborator

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;

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

martin added 4 commits January 25, 2019 16:29
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.
@martin-cs martin-cs force-pushed the fix/redirect-exception-handler-output branch from 821bc8e to 9816337 Compare January 25, 2019 16:32
@martin-cs
Copy link
Collaborator Author

Closed in favour of #3951 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants