MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Re: Tracebacks
At 05:17 PM 3/19/96 PST, you wrote:
>Has anybody written an traceback procedure that will identify the string
>where the problem is occuring, as well as the line? I would do this, but I
I have a traceback pretty-printer, which prints tracebacks like:
$lock_utils:parse_keyexp, line 2: Range error (E_RANGE)
[ this.player = args[2]; ]
... called from $nothing:Input to EVAL, line 18
... called from built-in function eval()
... called from $prog:eval_cmd_string* (this == ~ThwartedEfforts), line 7
[ value = debug ? eval(program) | $code_utils:eval_d(program); ]
... called from $prog:eval*-d d; (this == ~ThwartedEfforts), line 9
(End of traceback for task 1266711420)
But, my code requires a bunch of things which exist in E_MOO's core and most
likely don't exist in yours. Namely the mapping of object numbers to
strings and the ability to find out a core ref from an object number, stuff
on $prog_options, among others. I'm not about to find out all the
dependancies to make the code more portable.
>don't know enough yet. This would be useful for things like:
>1) Finding out *which* variable is not found.
This can usually be found from looking at the line of code in question. Of
course, to really debug problems like this, you'll need to look at the
entire verb anyway.
>2) Diagnosing stupid errors, like putting in to many or to few parens.
This is not handled with tracebacks.
>3) Figuring out if your program is going into a loop or something.
Again, this is something which requires knowledge of the program in
question. You could do things with E_MAXREC, but this only detects
recursion problems, not while(1) problems. I'd rather spend 2 minutes
trying to find the problem (and thus get more done) than spend 2 months
writing code to detect programming errors.
sidenote: Take a trip to the bookstore and pick up a copy of 'Code Complete'
(Microsoft Press). It's a great book, lots of stuff on how to write
programs so that 1) you don't make those kinds of mistakes, 2) they are easy
to detect if you do make them.
>If there is, I would love to hear about it. If there isn't, somebody should
>write it. If they won't, then I will sometime.
Somebody should write it? What demands! :)
Good luck writing such a beast! :)
Andy.
Home |
Subject Index |
Thread Index