< Previous by Date Date Index Next by Date >
  Thread Index  

[reSIProcate] exception handling


Hello,

Can someone explain the exception handling strategy in resip?  There are not
that many places that throw exceptions and for the places that do I am
wondering if they need to be there at all.  As a user of resip I am
concerned with all of the repercussions of having resip throw exceptions in
my app.  Even if I wrap all of my resip related code in try/catch blocks I
am still concerned that things will not be cleaned up correctly resulting in
memory leaks and inconsistent behavior.  For example,
DialogUsageManager::makeInviteSession creates a new InviteSessionCreator on
the heap, but down the line in the function call sequence you get to
SipMessage::ensureHeaders which throws an exception.  The
DialogUsageManager::makeInviteSession function does not try/catch so the
memory here is lost if this should throw and my app catches the exception.
This scenario may never throw an exception, but in general I question the
strategy behind using exceptions at all.  Referring to:
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.12 for some
outside information on the subject, I think that the resip exception
handling strategy would greatly benefit from similar guidelines.  

Another example would be the NameAddr class that throws in the constructor
if ParseBuffer() throws an exception.  Since NameAddr is such a fundamental
type, what happens if this throws somewhere in the dum or sipstack layers?
This can lead to some very inconsistent behavior if I catch the exception at
the thread level.

Thoughts?

Thanks,

-Justin