Changes between Version 56 and Version 57 of FAQ


Ignore:
Timestamp:
Sep 11, 2008 11:08:46 AM (16 years ago)
Author:
bennylp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FAQ

    v56 v57  
    3636=== It's an assertion, and not a crash, dammit! :) === #assert 
    3737 
    38 Very often we receive a report that PJSIP crashes, while actually it's ''just'' an assertion. This makes a big difference for us in terms of troubleshooting, since a crash means fatal bug, while assertion just serves as warning thus is not fatal. 
    39  
    40 In PJSIP, we use assertion as means to warn the developer that something unexpected has happened. This may due to some wrong assumption during development, some invalid value being passed, or some other mistakes done by the developer. The conventions are: 
    41  * assertion should only be raised for unexpected errors generated locally. For errors coming from external sources (such as a malformed SIP message received from remote), it must not raise assertion and rather the usual error handling must be performed. 
     38Very often we received a report that PJSIP crashes, while actually it's ''just'' an assertion. This makes a big difference for us in terms of troubleshooting, since a crash means fatal bug, while an assertion just serves as a warning thus it is not as fatal. 
     39 
     40In PJSIP, we use assertion as means to warn developers that something unexpected has happened. This may be due to some wrong assumption being made during development, some invalid values being used, or some other mistakes done by the developer. The developer can be you or me of course. The conventions that we use consistently are: 
     41 * assertion should only be raised for unexpected errors generated locally. For errors coming from external sources (such as a malformed SIP message received from remote), it must not raise assertion, and rather a usual error handling must be performed. 
    4242 * assertion must not replace a proper error handling, thus when assertion is disabled, the program should fallback to using error handling as usual. 
    4343 
    44 We use [http://www.pjsip.org/pjlib/docs/html/group__pj__assert.htm#gc98bea768b573f53432076a387864fb3 PJ_ASSERT_RETURN()] macro a lot. The idea of this macro is to raise an assertion during development so that any problems can be fixed early, and on the production release where assertion is disabled, the macro will revert to error handling. 
    45  
    46 So yes, '''you should disable assertion on the release version''' of the software. 
    47  
    48 In conclusion, please distinguish between assertion and crash when reporting a problem so that we can give the report the appropriate attention. 
     44We use [http://www.pjsip.org/pjlib/docs/html/group__pj__assert.htm#gc98bea768b573f53432076a387864fb3 PJ_ASSERT_RETURN()] macro a lot. The idea of this macro is to raise an assertion during development so that any problems found can be fixed early, and on the production release where assertion is disabled, the macro will revert to error handling so that the application will not terminate unexpectedly with ''Assertion failure'' error. 
     45 
     46So yes, '''you should disable assertion on the release version''' of the software. This is another convention that we use. 
     47 
     48In conclusion, please distinguish between assertion and crash when reporting a problem so that we can give the report the appropriate attention.  
    4949 
    5050----