[serialization] unwinding "stack" of object during loading
Hello, Consider the following structure: struct outer { inner_type1 inner1_; inner_type2 inner2_; template<class Archive> void HostPort::load(Archive &ar, const unsigned int version) { ar >> BOOST_SERIALIZATION_NVP(inner1_); ar >> BOOST_SERIALIZATION_NVP(inner2_); } }; Assume that loading of inner1_ throws exception. Is there a way to "unwind" the "stack" of objects gracefully (i.e. to skip until some "end" marker of inner1_), and to proceed loading the next inner object normally? Thanks.
Igor R wrote:
Hello,
Consider the following structure:
struct outer { inner_type1 inner1_; inner_type2 inner2_;
template<class Archive> void HostPort::load(Archive &ar, const unsigned int version) { ar >> BOOST_SERIALIZATION_NVP(inner1_); ar >> BOOST_SERIALIZATION_NVP(inner2_); } };
Assume that loading of inner1_ throws exception. Is there a way to "unwind" the "stack" of objects gracefully (i.e. to skip until some "end" marker of inner1_), and to proceed loading the next inner object normally?
Note that the the serialization library does throw exceptions on failure. These exceptions are documented in the manual. You should be able to catch these exceptions in your own save/load functions. I can't say to what extent one might be able to recover. Implementing this would likely require more elaborat save/load functions. Robert Ramey
Thanks.
Note that the the serialization library does throw exceptions on failure. These exceptions are documented in the manual. You should be able to catch these exceptions in your own save/load functions. I can't say to what extent one might be able to recover. Implementing this would likely require more elaborat save/load functions.
Yes, I know it throws exceptions that I can catch, but the question is
how the library would behave in the following case.
Consider the following xml small item:
<item class_id="2" tracking_level="0" version="1">
<px class_id="3" tracking_level="1" version="0" object_id="_0">
Igor R wrote:
Note that the the serialization library does throw exceptions on failure. These exceptions are documented in the manual. You should be able to catch these exceptions in your own save/load functions. I can't say to what extent one might be able to recover. Implementing this would likely require more elaborat save/load functions.
Yes, I know it throws exceptions that I can catch, but the question is how the library would behave in the following case. Consider the following xml small item: <item class_id="2" tracking_level="0" version="1"> <px class_id="3" tracking_level="1" version="0" object_id="_0">
134959408 somename </px> </item> 0 0 12345 If reading
sub-item throws in the middle, will the stream remain in a consistent state, i.e. will it skip until after </info>
Well it certainly won't do that. Basically, exceptions are thrown only if there's no other option. I would expect the underlying text stream to be in an undefined state.
(or some outer closing tag)? If not, can I take some measures to force this?
you could try, but I wouldn't expect such measures to be reliable. The real question is what kind of exception could occur which would permit you to read more of the stream. if you can still read the stream then it's likely to be a programming error - e.g. save/load don't match and to my mind trying to recover from these situation either hides an error or compounds the damage. Robert Ramey
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
<...>
The real question is what kind of exception could occur which would permit you to read more of the stream. if you can still read the stream then it's likely to be a programming error - e.g. save/load don't match and to my mind trying to recover from these situation either hides an error or compounds the damage.
The exception is "unregistered_class" - why is it thrown is another question, but unfortunately we couldn't find the answer so far. However, the inner object that fails to get red is not critical, so I wanted to try skipping it.
Igor R wrote:
<...>
The real question is what kind of exception could occur which would permit you to read more of the stream. if you can still read the stream then it's likely to be a programming error - e.g. save/load don't match and to my mind trying to recover from these situation either hides an error or compounds the damage.
The exception is "unregistered_class" - why is it thrown is another question, but unfortunately we couldn't find the answer so far. However, the inner object that fails to get red is not critical, so I wanted to try skipping it.
Ahhh - you can't find the error, so you think you can hide it? I feel you're pain and this approach SEEMS easier but trust me it's not. If you manage to hide it, it will just bite you in the future - and it will be a lot harder to find - since you hide it. Robert Ramey
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Igor R -
Robert Ramey