Re: [reSIProcate] replacing assertions
I guess it depends how consistently resip_assert(..) is used. Also,
would we need to worry about additional try/catch blocks sneaking in to
the resip code (e.g. because we want to 'internally' handle certain
exceptions that are now thrown... )
Jeremy
------ Original Message ------
From: "Daniel Pocock" <daniel@xxxxxxxxxx>
To: "Jeremy Geras" <jgeras@xxxxxxxxxxxxxxx>; "Scott Godin"
<sgodin@xxxxxxxxxxxxxxx>
Cc: "resiprocate-devel@xxxxxxxxxxxxxxx"
<resiprocate-devel@xxxxxxxxxxxxxxx>
Sent: 12/18/2014 12:47:58 AM
Subject: Re: [reSIProcate] replacing assertions
>On 17/12/14 21:20, Jeremy Geras wrote:
>> One potential issue for us -- we're currently using resip + DUM on
>>some
>> firmware, where we'd prefer to completely disable exceptions.
>>Currently
>> we enable them and just "live with" the extra binary size. Adding
>>more
>> exceptions might cause issues.
>
>Thanks for this feedback, this is one of the reasons I put these ideas
>on the list before changing anything
>
>Would you prefer something like a resip_assert() macro that you can
>define the way you want?
>
>Or would you prefer to see some methods tweaked to return error codes
>instead of throwing exceptions?
>
>The reasons I suggest exceptions:
>
>a) we don't have to modify the API to return error codes from functions
>that fail, we can just introduce exceptions be defining the
>resip_assert
>macro to throw. Unhandled exceptions just stop the program like an
>assert anyway.
>
>b) constructors can't return an error code if they are given invalid
>data or can't initialize. We have a lot of logic in constructors and
>changing them would be quite dramatic.
>
>
>