>> Assert.h is a nice debug library -- for non-realtime programs. Assert
>> has the bad problem of "crashing" the MUD if you use it. Instead, it
>> is a better idea to do your own bug testing, and if something doesn't
>> work right, print an error and either try to exit the MUD gracefully
>> if possible or move on if it's not a completely horrible bug.
>>
>
>Most any assertion you will put in will be to check to see if the mud
>will crash in an unrecoverable way anyway, and it is great to see
>if array bounds are being overritten, if pointers are null, or anything
>else fatal.
I think that we're all talking on personal debug preferences. I,
personally, absolutely hate to see one spec-proc or spell that
requests the wrong address, references the wrong variable, or passes
the wrong parameter because of bad programming on the part of
one coder crash the entire MUD. For one thing, as good as gdb, adb,
or dbx are, they still sometimes miss the mark. Personalised debug
messages logged to a file can be more helpful (if you design them
correctly), to me, than the stack trace of gdb.
The following are examples of the levels I would put bug responses.
For me, the only times I want the mud to crash are in these cases:
1. If player or world files cannot be found
2. If the socket initialisation functions fail
3. Finding a corrupt data file
Places I'd rather the MUD try to exit gracefully:
1. Writing to player or data files
Places I'd rather just see an error message and have the MUD move on:
1. Spells or skills execution
2. Special procedure execution
3. When variables are referenced as null.
Thanks,
--
Kenneth G. Cavness
Software Engineer
Proxicom, Inc.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST