You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using exceptions is the only way to parse xml and have it not crash the program on a formatting error. So if we can't use exceptions, rapidxml becomes unusable if you want to gracefully handle bad formatting.
The usage of a globally linked error handler is also problematic, multiple places in the code using rapidxml w/o exceptions will cause linking problems, and it requires workarounds to wrap the #include <rapidxml.hpp> in a namespace so multiple error handlers can be provided.
Ideally a function pointer object could be provided to rapidxml that would allow us to do our own exception handling, that could contain user data where we can map to our own local information, so the filename and such can be printed in a thread-safe manner.
The text was updated successfully, but these errors were encountered:
So what I'm thinking is we have a rapidxml::xml_document<>::set_error_handler(...) function which takes a std::function<...>(...) (types to be figured out later).
Then the code can call that instead of the nasty macro.
I'll need to fiddle about a bit to try to guess what will work in the C++03 that rapidxml targets; I think I've avoided introducing C++11 so far.
Using exceptions is the only way to parse xml and have it not crash the program on a formatting error. So if we can't use exceptions, rapidxml becomes unusable if you want to gracefully handle bad formatting.
The usage of a globally linked error handler is also problematic, multiple places in the code using rapidxml w/o exceptions will cause linking problems, and it requires workarounds to wrap the #include <rapidxml.hpp> in a namespace so multiple error handlers can be provided.
Ideally a function pointer object could be provided to rapidxml that would allow us to do our own exception handling, that could contain user data where we can map to our own local information, so the filename and such can be printed in a thread-safe manner.
The text was updated successfully, but these errors were encountered: