Hi Gabrielle,
Thanks for answering all those emails, including mine.
> Once a script is loaded in memory, there aro no more "lines", so
> REBOL cannot help you that. It tells you the name of the function
> where the error happened, howver.
Unfortunately, that is not always the case. here's an example:
; Define object
Initcode: make object! [
displayscreen: func [p-type /local line-count] [
switch p-type [
"A" [Line-Count: Line-Count + 1]
]
]
]
;define function that uses the object
mainfunc: func [] [initcode/displayscreen "A"]
; Run the function
MainFunc
; Result
** Script Error: Cannot use add on none! value
** Where: switch
** Near: Line-Count: Line-Count + 1
It tells me I'm in the middle of a switch statement, not the
InitCode/DisplayScreen function. Could do better!
> Also, you might just insert some probes around the places where
> you use that code, so that you can easily spot the bug.
When I'm developing code, i normally have a pretty good idea of which bit has
gone belly-up, and the code is peppered with Prints and stuff at that stage.
I am specifically looking for a better quality error message for when the
code has been deployed in the field. There will be bugs, and I don't want to
spend the first half hour in solving a bug report simply trying to work out
which function has the problem.
The only workaround I have so far is Andrews. That I make sure each data name
is unique to each function, so any line of code is traceable to that
function. But I really, really do not want to be writing code like
InitObject-DisplayScreen-Line-Count: InitObject-DisplayScreen-Line-Count + 1
just to help me in debugging:
** Script Error: Cannot use add on none! value
** Where: switch
** Near: InitObject-DisplayScreen-Line-Count:
InitObject-DisplayScreen-Line-Count + 1
There surely must be a better way! Any ideas?
Thanks,
Sunanda.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
