Skip to content

operator>> writes to stderr #665

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

Closed
wolframroesler opened this issue Sep 8, 2017 · 2 comments
Closed

operator>> writes to stderr #665

wolframroesler opened this issue Sep 8, 2017 · 2 comments

Comments

@wolframroesler
Copy link
Contributor

Hi,

is it intentional that operator>> writes to stderr before throwing an exception in 1.8.3? IMHO it shouldn't do that - it's an unexpected side effect, and it messes up the application's error output. Not every bad input to the JSON parser is an error I want logged on stderr. No other JsonCpp function writes anything to stderr before throwing. Also, it didn't do that in 1.8.0. Also, it uses fprintf which it not really C++-like (which makes me hope it's just some forgotten debug output).

I suggest removing the fprintf(stderrr,...), or #ifdefing it out if you really need it.

Thanks

Wolfram

JSONCPP_ISTREAM& operator>>(JSONCPP_ISTREAM& sin, Value& root) {
  CharReaderBuilder b;
  JSONCPP_STRING errs;
  bool ok = parseFromStream(b, sin, &root, &errs);
  if (!ok) {
    fprintf(stderr,
            "Error from reader: %s",
            errs.c_str());

    throwRuntimeError(errs);
  }
  return sin;
}
@wolframroesler
Copy link
Contributor Author

Submitted it as a pull request: #666

@cdunn2001
Copy link
Contributor

It's been there since 2011: 2b853c4

But I think it was an accident. The idea was, back then, exceptions could be turned off/on with a macro. A stream operator has no way to indicate failure, so we wrote to stderr in case. But I don't think that has been needed or helpful in many years.

Thanks for noticing.

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

No branches or pull requests

2 participants