serialisation use of asserts versus throw ?
This is question about use of asserts in boost serialisation. As a program migrates from one release to another the api changes. This is expected. In my case I have client/server that uses boost serialisation. I was expecting an throw due to the incompatibility not a an assert. The assert crashes my client, giving no chance for recovery, and informing the user that they are using previous out of date release/server. In may case: boost_iarchive.cpp inline const basic_pointer_iserializer * 399 basic_iarchive_impl::load_pointer( 400 basic_iarchive &ar, 401 void * & t, 402 const basic_pointer_iserializer * bpis_ptr, 403 const basic_pointer_iserializer * (*finder)( 404 const boost::serialization::extended_type_info & type_ 405 ) 406 407 ){ ..... 436 BOOST_ASSERT(NULL != bpis_ptr); 437 class_id_type new_cid = register_type(bpis_ptr->get_basic_serializer()); 438 int i = cid; 439 cobject_id_vector[i].bpis_ptr = bpis_ptr; 440 BOOST_ASSERT(new_cid == cid); // yikes How do people get round this issue, where old and new release of software need to co-exist ? Would it be possible to use a #define to configure use of asserts or throw ? Any help apperciated . Best regards, Ta, Avi
On Thu, Sep 6, 2012 at 6:19 AM, Avi Bahra
This is question about use of asserts in boost serialisation.
As a program migrates from one release to another the api changes. This is expected. In my case I have client/server that uses boost serialisation.
I was expecting an throw due to the incompatibility not a an assert. The assert crashes my client, giving no chance for recovery, and informing the user that they are using previous out of date release/server.
This is an interesting policy point that's broader than the serialization library. The Boost.Coroutine library is being reviewed right now, and one reviewer has requested that the library use assert rather than throw for precondition violations. Maybe I'm conflating failure conditions that are conceptually distinct. If so, I apologize. If there is already text on the Boost website that clarifies when a Boost library should use assert vs. throw, please point me to it. If there is not -- perhaps there should be.
On Thu, Sep 6, 2012 at 12:19 PM, Avi Bahra
Would it be possible to use a #define to configure use of asserts or throw ?
See BOOST_ENABLE_ASSERT_HANDLER from http://www.boost.org/doc/libs/1_51_0/libs/utility/assert.html. BTW, are you deploying debug software? BOOST_ASSERT disappears from release builds AFAIK, while BOOST_VERIFY does not. --DD
Avi Bahra wrote:
This is question about use of asserts in boost serialisation.
As a program migrates from one release to another the api changes. This is expected. In my case I have client/server that uses boost serialisation.
archive versioning is designed to address this concern.
I was expecting an throw due to the incompatibility not a an assert. The assert crashes my client, giving no chance for recovery, and informing the user that they are using previous out of date release/server.
Assert is used when a condition occurs which seems to indicate that no reliable recovery is possible. This is preferred over some feeble attempt at recovery which only will hide the error.
How do people get round this issue, where old and new release of software need to co-exist ?
Boost serialization archive versioning.
Would it be possible to use a #define to configure use of asserts or throw ?
nope. Having said all this, sometimes one makes an error and assigns an Assert to a situation which is actually a reoverable runtime error. Those are bugs for which a trac item may be submitted. I don't think this is the case for your situation. Robert Ramey
participants (4)
-
Avi Bahra -
Dominique Devienne -
Nat Linden -
Robert Ramey