P4DTI issue job000060

TitleAssertions and run-time errors conflated
Assigned userGareth Rees
DescriptionAssertions should be things which the programmer believes will always be true. Other conditions are run-time errors and should have recovery code, and try not to be fatal errors in the replicator, as it has to be a reliable daemon or service.
Assertions probably should be fatal, and provide plenty of backtrace information for debugging.
AnalysisClean up and carefully divide assertions from consistency checks and regularize the error recovery code.
See also <http://info.ravenbrook.com/mail/2000/12/07/13-25-21/0.txt>. RB 2000-12-07
How foundinspection
Evidence<http://www.ravenbrook.com/project/p4dt...c/2000-10-17/release-0.3.1-test-report/> item 31
<http://www.ravenbrook.com/project/p4dti/doc/2000-10-27/perforce-alpha-test/> items 2, 13, 14
<http://www.ravenbrook.com/project/p4dti/doc/2000-10-24/teamshare-psg-alpha-test/> item 5
Observed in0.3.2
Created byRichard Brooksby
Created on2000-11-22 12:48:09
Last modified byGareth Rees
Last modified on2001-12-10 19:02:16
History2000-11-22 RB Created from sources (see evidence).
2000-12-07 RB Added analysis reference to e-mail.


Change Effect Date User Description
5389 closed 2000-12-04 18:45:31 Gareth Rees Merged branch/2000-12-04/no-conflicts back into master sources.
5180 open 2000-11-30 15:21:24 Gareth Rees I now use assert only for genuine assertions (indicating things that shouldn't be able to happen, like a function receiving an argument of the wrong type). Run-time errors are raised with an appropriate message, not asserted.