Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Better error messages?

 [1/18] from: sunandadh::aol::com at: 6-Dec-2001 9:03


Here's a typical console error message:
>> do %BigScript.r
** Script Error: CleanedUpValue has no value ** Where: switch ** Near: set in last LayoutData 'Text The trouble I'm having is that BigScript.r consists of about ten object, each encapsulating several functions, and each object is in a separate source file. But the standard error message doesn't tell me which source file, or which object, or even which function. Is there any way of pinpointing the location more precisely? (I've tried putting the whole app into a Try block, but the Error object is no more precise). Thanks, Sunanda.

 [2/18] from: al:bri:xtra at: 7-Dec-2001 6:52


> ** Near: set in last LayoutData 'Text
Try searching your script for: set in last LayoutData 'Text it should be near there. Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [3/18] from: sunandadh:aol at: 6-Dec-2001 16:36


Hi Andrew,
> Try searching your script for: > set in last LayoutData 'Text > it should be near there.
Thanks for that. But i was wondering if there was something better, something more precise. Most other languages you can pinpoint a failure to the line. Rebol just seems to give a hint. And the hint don't work well unless the line Rebol quotes is unique. set in last LayoutData 'Text is used half a dozen times to change the text of a VID object, so a source scan isn't really close enough, even for government work. Sunanda.

 [4/18] from: al:bri:xtra at: 7-Dec-2001 16:37


Sunanda wrote:
> set in last LayoutData 'Text is used half a dozen times to change the text
of a VID object, so a source scan isn't really close enough, even for government work. Change: set in last LayoutData 'Text into a function. Perhaps call it: 'Change-Text ?
> Most other languages you can pinpoint a failure to the line. Rebol just
seems to give a hint. It's a bit hard for Rebol to do that because Rebol can be constructed and 'do-ne. For example, where is the line number in: do test ? 'test could be a block filled with all sorts of words that have been 'append-ed to, 'compose-d or 'reduce-d, or even entered from the keyboard! Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [5/18] from: sunandadh:aol at: 7-Dec-2001 5:37


[Al--Bri--xtra--co--nz] writes: Hi Andrew
> > set in last LayoutData 'Text is used half a dozen times to change the text > of a VID object, so a source scan isn't really close enough, even for > government work. > > Change: > set in last LayoutData 'Text > into a function. Perhaps call it: 'Change-Text ?
I don't think that would help. it certainly wouldn't help in the case of an error like: ** Throw Error: Return or exit not in function ** Near: Return true (You can coax that one out of make-dir with suitably bad input. But it could be an error in any one of dozens of mezzanines whose source I would not recognise on sight.)
> > Most other languages you can pinpoint a failure to the line. Rebol just > seems to give a hint.
<<quoted lines omitted: 3>>
> ? 'test could be a block filled with all sorts of words that have been > 'append-ed to, 'compose-d or 'reduce-d, or even entered from the keyboard!
Okay, maybe it can't be done in all cases. But what I'd like to see is some way to access or print the calling stack at point of failure---so I can see (for example) that we failed in Function init/display, which was called by Function init/paint which was called by Function Startup. Rebol must have a calling stack to be able to honour the 'return statements. If Rebol won't do it for me, I'm looking to find out how to do it myself, which I guess would involve wrapping the application in a Try block and then sifting the damage info in the system object. But there is no way I'd want to deploy into the field an application whose error pinpointing as lackadaisical as Rebol's is today. So any suggestions or pointers to the useful bits in the system object would be greatly appreciated. Thanks, Sunanda.

 [6/18] from: g:santilli:tiscalinet:it at: 7-Dec-2001 12:17


[SunandaDH--aol--com] wrote:
> Thanks for that. But i was wondering if there was something better, something > more precise. Most other languages you can pinpoint a failure to the line. > Rebol just seems to give a hint.
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. Also, you might just insert some probes around the places where you use that code, so that you can easily spot the bug. HTH, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [7/18] from: rotenca:telvia:it at: 7-Dec-2001 13:45


Hi Gabriele,
> > Thanks for that. But i was wondering if there was something better,
something
> > more precise. Most other languages you can pinpoint a failure to the line. > > Rebol just seems to give a hint. > > 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.
I disagree: REBOL could help. The near field of error object could be better: it could store a pointer to the block code where the error happens not a fixed length 5 copy of it. With this copy we only could try to identify the exact point using local words if at least one of them appears in the near block. With a pointer in many cases (not always) we could go back and forward to view the context of failing code. At least, the lenght of copy should be changed by user. The near pointer is so bad that sometimes it never shows the exact point of error, because of len 5:
>> err: disarm try [1 / 3 / 5 / 0] err/near
== [1 / 3 / 5] --- Ciao Romano

 [8/18] from: sunandadh:aol at: 7-Dec-2001 10:05


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.

 [9/18] from: nitsch-lists:netcologne at: 8-Dec-2001 5:52


RE: [REBOL] Re: Better error messages? [SunandaDH--aol--com] wrote:
> Hi Gabrielle, > > Thanks for answering all those emails, including mine.
<<snip>>
> It tells me I'm in the middle of a switch statement, not the > InitCode/DisplayScreen function. Could do better!
<<quoted lines omitted: 6>>
> spend the first half hour in solving a bug report simply trying to work out > which function has the problem.
interesting point. thats more the job of logging then of error-messages? i played a bit with it, and now there is a prototype http://www.reboltech.com/library/scripts/error-logger.r on the script-library. your function would look like displayscreen: func [[catch] p-type /local line-count] [ mission "displaying screen" [ switch p-type [ "A" [Line-Count: Line-Count + 1] ] ] ] then and on error logs its mission-goal and the error to %error-log.txt . of course you have to customize it ;-)
> 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
<<quoted lines omitted: 8>>
> Thanks, > Sunanda.
-Volker

 [10/18] from: sunandadh:aol at: 8-Dec-2001 3:47


Hi Volker,
> Interesting point. > thats more the job of logging then of error-messages?
<<quoted lines omitted: 11>>
> then and on error logs its mission-goal and the error to %error-log.txt . > of course you have to customize it ;-)
Interesting reply! Thanks for putting the work in. That's an approach that solves the problem. And it gets me wondering if it could be done the other way round. For example, I define a function called (say) LoggedFunc: LoggedFunc: func [Params ExecuteBlock] [Implementation] which I can use as normal: displayscreen: Loggedfunc [p-type /local line-count] [ switch p-type [ "A" [Line-Count: Line-Count + 1] ] ] The [Implementation] stacks that "DisplayScreen" has been called, TRYs the ExecuteBlock as a normal Func, and unstacks the call on 'Return. And, of course, prints the stack on error. This would be less "intrusive", and could easily be "turned off" for high performance (LoggedFunc: :func I think would nix it). Trouble is I got not idea how to do it. Or rather, I see a some of difficult problems: -- How to get the function name as a string? -- How to pass refinements? -- How to distinguish LoggedFun's /Locals from my functions locals? Any help on this would again be greatly appreciated. Thanks again, Sunanda.

 [11/18] from: nitsch-lists:netcologne at: 8-Dec-2001 14:08


RE: [REBOL] Re: Better error messages? [SunandaDH--aol--com] wrote:
> Hi Volker, > > Interesting point.
<<quoted lines omitted: 14>>
> Interesting reply! Thanks for putting the work in. That's an approach that > solves the problem.
Oh, thank you :)
> And it gets me wondering if it could be done the other way round. For > example, I define a function called (say) LoggedFunc:
<<quoted lines omitted: 13>>
> problems: > -- How to get the function name as a string?
either Loggedfunc: func[word args block][set word func args block] displayscreen: none ;mark it for context Loggedfunc 'displayscreen [p-type /local line-count] [ switch p-type [ "A" [Line-Count: Line-Count + 1] ] ] (ugly) or Loggedfunc: func['word args block][word func args block] Loggedfunc displayscreen: [p-type /local line-count] [ switch p-type [ "A" [Line-Count: Line-Count + 1] ] ] hack: we use a set-word, so make object! recognizes our word as local. not real rebol, only one prefix function, not really good. or something like my-context: logging context[ displayscreen: Loggedfunc [p-type /local line-count] [ switch p-type [ "A" [Line-Count: Line-Count + 1] ] ] ] ] 'logging easy to forget, but i like it most. and now i develop magic: (starts mumbling, various miraculous words later:) { AND WITH MORE SERVICE (update to http://www.reboltech.com/library/scripts/error-logger.r 1.1.0) } Initcode2: LOGGING context [ displayscreen: LOGGED func [p-type /local line-count] [ switch p-type [ "A" [Line-Count: Line-Count + 1] ] ] ] { 'LOGGED sets a marker 'its-a-logging-func in the functions body. 'LOGGING scans all functions in objects for marker and modifies them to use 'mission. RESULT: } Initcode2: make object! [ displayscreen: func [[catch] p-type /local line-count] [ mission "displayscreen:" [ switch p-type [ "A" [Line-Count: Line-Count + 1] ]]] ] {oh yes, to disable logging use} logging: logged: func [arg] [:arg]
> -- How to pass refinements? > -- How to distinguish LoggedFun's /Locals from my functions locals?
simple: pass nothing :) i take a ready-made and bound function and modify its body. because i add my words after binding, the same name can be used local and in my context. (similar to using the same index with two different arrays). so using 'mission local should be ok. only problem is 'its-a-logging-func, so it has a hopefully rare name. could be checked smarter, because same? (in my-context 'its-a-logging-func) (in another-context 'its-a-logging-func) gives false, but then the code gets more complex. also i can use displayscreen: func [p-type /local line-count] [ 'ITS-A-LOGGING-FUNC switch p-type [ "A" [Line-Count: Line-Count + 1] ] ] by hand this way. don't know if it makes sense..
> Any help on this would again be greatly appreciated. > > Thanks again, > Sunanda.
Have a lot of fun in the field :) -Volker

 [12/18] from: g:santilli:tiscalinet:it at: 8-Dec-2001 17:44


Hello Sunanda! On 07-Dic-01, you wrote: [...] S> ** Script Error: Cannot use add on none! value S> ** Where: switch S> ** Near: Line-Count: Line-Count + 1 S> It tells me I'm in the middle of a switch statement, not the S> InitCode/DisplayScreen function. Could do better! Hmm... maybe the [throw] attibute could be used for that too... RT? Currently it does not work because the SWITCH function is no more special than your function; REBOL just know that the code that produces an error is running "inside" the SWITCH function. Maybe the solution would be to include a full stack dump instead of just providing the topmost function name. I.e.: a: func [] [make error! "Bomb!"] b: func [] [a] c: func [] [b] should give out: Where: [c b a] or something like that. S> I am specifically looking for a better quality error message S> for when the code has been deployed in the field. There will S> be bugs, and I don't want to spend the first half hour in S> solving a bug report simply trying to work out which function S> has the problem. Maybe we could just write a REP and send it to Carl? I think having a pointer in error/near and a stack dump in error/where should be rather easy to implement for RT. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [13/18] from: g:santilli:tiscalinet:it at: 8-Dec-2001 17:29


Hello Romano! On 07-Dic-01, you wrote: RT> could be better: it could store a pointer to the block code RT> where the error happens not a fixed length 5 copy of it. With Indeed, and the copy/part ... 5 could be done when printing the error message. I was just saying it cannot tell the line number, not that it couldn't provide better reports. :) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [14/18] from: sunandadh:aol at: 9-Dec-2001 18:27


Hi Gabrielle,
> a: func [] [make error! "Bomb!"] > b: func [] [a]
<<quoted lines omitted: 4>>
> having a pointer in error/near and a stack dump in error/where > should be rather easy to implement for RT.
That'd be a good solution I'd be happy to write the Rep. Is there some protocol involved here, or is it just an email to feedback? Volker has come up with what looks to me like an excellent workaround, demonstrating once again the flexibility of Rebol and the ingenuity of this list's inhabitants....But it'd be even better to have something as basic as error reporting built into the environment. Sunanda.

 [15/18] from: sunandadh:aol at: 9-Dec-2001 18:26


Hi Volker,
> > And it gets me wondering if it could be done the other way round. For > > example, I define a function called (say) LoggedFunc:
Thanks for your long reply, and sample code. What you've done is very clever, and if I understand it right, it will be of interest to anyone who is developing Rebol code for use by others. Can I summarise what I think you've done for everyone's benefit? Problem: Rebol error messages give way to little context. Useful for development maybe, but underpowered for code deployed in the field. Volker's solution. 1. Be structured. Embed all Funcs in Objects: MyObject1: [Myfunc1: func [...] [...] Myfunc2: func [...] [...] ] MyObject2: [Myfunc1: func [...] [...] Myfunc2: func [...] [...] ] This is pretty good practice anyway. 2. For any of these functions you want a better set of reporting on, defined the with the Logged marker word: MyObject1: [Myfunc1: logged func [...] [...] Myfunc2: func [...] [...] ] MyObject2: [Myfunc1: logged func [...] [...] Myfunc2: logged func [...] [...] ] (So for some reason, I've decided not to get a better oversight on MyObject1/MyFunc2) 3. Before you make your first object call, run Volker's initialisation code: Logging MyObject1 Logging MyObject2 (This replaces the 'logged marker word with some magic). 4. To do this, you need Volker's functions, available at: http://www.reboltech.com/library/scripts/error-logger.r (this is a bit of a jumble of payload code, test code, examples and development history. You just need the functions from the comment "control your logging here" onwards.) Thanks Volker! Sunanda.

 [16/18] from: nitsch-lists:netcologne at: 10-Dec-2001 20:21


RE: [REBOL] Re: Better error messages? Excellent. I replaced my usage-part with yours, hope its ok ;-) -Volker [SunandaDH--aol--com] wrote:

 [17/18] from: g:santilli:tiscalinet:it at: 10-Dec-2001 19:35


Hello [SunandaDH--aol--com]! On 10-Dic-01, you wrote: S> I'd be happy to write the Rep. Is there some protocol involved S> here, or is it just an email to feedback? I think it just needs to be written in MakeSpec format... S> Volker has come up with what looks to me like an excellent S> workaround, demonstrating once again the flexibility of Rebol Indeed. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [18/18] from: allenk:powerup:au at: 11-Dec-2001 14:19


> From: Gabriele Santilli <[g--santilli--tiscalinet--it]> > Subject: [REBOL] Re: Better error messages?
<<quoted lines omitted: 5>>
> S> here, or is it just an email to feedback? > I think it just needs to be written in MakeSpec format...
Some example reps for you to look at. Cheers, Allen K
This message was sent through MyMail http://www.mymail.com.au

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted