-
Notifications
You must be signed in to change notification settings - Fork 2.7k
CharReader: Add StructuredError #1281
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
CharReader: Add StructuredError #1281
Conversation
50ae06e
to
c56822b
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.
OurReader
already has a getStructureErrors()
, it's just not exposed through the Json::CharReader
interface.
It's expected and true that parse
modifies the reader, as it's a non-const member function.
So after a parse
call the CharReader
is holding metadata about the parse, including the structured errors.
I would propose a much smaller change here where we don't add a parse overload, but add a getStructuredErrors
accessor.
I feel like adding parse overloads is tricky because we'll end up with a Cartesian product of all the ways to specify inputs times all the possible kinds of output a caller might want, all as virtual functions. Currently parse(...)
is not overloaded at all. Thee's just one virtual function operating on a char array. You can omit the errs if you don't want them but they provide a simple way to get at the getFormattedErrorMessages
of the underlying OurReader.
I think what's missing from the API here are API calls that tunnel through to the underlying OurReader more directly. We have only parse
currently. I feel like we could have getStructuredErrors
as well.
This sounds fine to me, and would still accomplish what I want. I do worry about this breaking binary compatibility. Source compatibility would be fine, but adding a new
|
c56822b
to
c40c334
Compare
It sounds like you might be saying that this is a unique concern of I don't think |
I am not. It is not unique to
Yes.
Could you explain what you mean by this? I'm guessing it's something like: std::vector<CharReader::StructuredError> CharReader::getStructuredErrors() const
{
auto const* impl = dynamic_cast<OurCharReader*>(this);
return impl->reader_.getStructuredErrors();
} with perhaps a middle layer for accessing the |
By the way, I am also working on a PR which adds the ability to obtain the Thoughts? |
Close but I would not do So it would be: CharReader {
public:
std::vector<StructuredError> getStructuredErrors() const;
/** apologetically virtual only for ABI compatibility. Not an extension point, so `final`. */
virtual bool parse(etc...) final;
private:
class Impl; // Privately provides the polymorphic interface that CharReader provides today.
std::unique_ptr<Impl> _impl;
};
// In cpp file to prevent inlining and control visibility.
class CharReader::Impl {
public:
virtual ~Impl() = default;
virtual bool parse(etc...) = 0;
virtual std::vector<StructuredError> getStructuredErrors() const = 0;
};
auto CharReader::getStructuredErrors() const -> std::vector<StructuredError> {
return _impl->getStructuredErrors();
}
bool CharReader::parse(etc...) {
return _impl->parse(etc...);
}
|
Unfortunately, adding the |
That's true. We could solve that by making it a member of a compatibility Wait nobody outside our .so knows how big a CharReader is. We only give pointers. So this isn't a problem. |
Not according to this simple test program: #include <iostream>
#include <json/reader.h>
int main()
{
std::cout << sizeof(Json::CharReader) << std::endl;
return 0;
} My machine shows it as |
I'd say the I could clarify by saying that "nobody outside our .so knows how big any |
That is a good point. Perhaps adding a member would be safe after all. However, please see my proposal above regarding string keys which would certainly require breaking ABI compatibility. I'll open a separate issue for that, since it's orthogonal to this PR. But if we went through with it, it would give us a chance to clean up the |
Please see #1283. |
While I understand and agree with your concerns on ABI compatibility for virtual methods, it's much more likely to be an issue on Linux than on Windows. I don't think we need to bump the major version number. Only the soversion counter.
People should not be using cmake, IMO, but if someone has a problem with ABI compatibility using cmake on Windows, they can rebuild the consuming code. So I'm fine with your new virtual function as is. All that said, I still like Billy's idea better. Please rebase this and modify according to @BillyDonahue 's suggestion. Then bump the minor version number. (I don't think we'll need to bump |
Thanks. I'm a little busy with other things at the moment and might not get to this for a while, but I will come back when I can. |
The move from
Json::Reader
toJson::CharReader
omitted the ability to get structured error messages from the parser. Clients which want to extract the line and column information have to parse the returned string. Add a newgetStructuredErrors()
method which exposes the error as structured data instead of a string.