Re: [reSIProcate] replacing assertions

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

I believe there are two main types of assertions in resip:

1.  Assertions that really signify a bug in the resip stack.  These are mainly in the stack and rutil projects.

2.  Assertions caused by miss-use of the public API's.  Most of these are in the DUM API's.  ie:  attempting things in an Invite session when in the wrong state.

I think the main issue is with the assertions that fall into #2.  I would like to see a sweep of the DUM code to convert the ones that make sense from assertions to throws.  I've already done some this for the provideOffer and provideAnswer API's.  

Note:  In most cases the assertions that fall into #1 will not benefit from a conversion to throw.  These are typically triggered in internal bug conditions only where throwing or continuing through the assertion would not fix the damage.  It's also quite likely that many code locations that do #1 assertions would not catch exceptions anyway.

Scott

 

On Fri, Dec 12, 2014 at 7:46 AM, Daniel Pocock <daniel@xxxxxxxxxx> wrote:

There are currently a lot of assertions in the code

Disabling them with NDEBUG is not really an option as most of them are actually performing essential checks on things.

I was thinking that it may be worthwhile to create a macro called resip_assert and replace all the assert statements with that.

People could then choose between two or more definitions of this macro, e.g. one that does a normal assert:


        #define resip_assert(x) assert(x)


and another that throws an exception


#define resip_assert(x) if((x)==0) throw std::runtime_error("assertion at " __FILE__ ":" __LINE__);


This doesn't completely eliminate the problem but it may be a useful step towards adding more specific exceptions.

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel