Topic: list of error meanings...

[andrew_nao]

a while ago someone had posted a website with errors meanigns
consp
stingp
etc...

does anyone remember this website? or have a list of the errors and meanings?

[CAB]

http://www.lee-mac.com/errormessages.html

[andrew_nao]

thank you once again

[Lee Mac]

Thanks CAB; I'm glad you find the reference useful Andrew 

[irneb]

Nice page Lee. One thing I'm not sure about: the difference between the consp and listp error. They seem to mean the exact same thing. Is there perhaps one scenario where consp is sent rather than listp, e.g. when a dotted pair is expected, not just a list?

[Lee Mac]

Nice page Lee. One thing I'm not sure about: the difference between the consp and listp error. They seem to mean the exact same thing. Is there perhaps one scenario where consp is sent rather than listp, e.g. when a dotted pair is expected, not just a list?

Thanks Irné 

Whilst writing the reference, I also attempted to ascertain the difference between the consp & listp argument type error messages, but as far as I can remember, I couldn't find any underlying reason why consp is returned rather than listp for some functions, for example:

Code: [Select]

_$ (nth 0 nil)
; error: bad argument type: consp nilSurely this should be listp since nth requires a list argument, not a dotted pair?

Code: [Select]

_$ (append 'a)
; error: bad argument type: listp AThis seems logical since append cannot accept a dotted pair argument (bad list error).

Code: [Select]

_$ (assoc 'a 'a)
; error: bad argument type: listp AAgain logical since assoc will return a bad association list error if fed a dotted pair.

In summary:

Code: [Select]

Function          Error Data Type
=================================
append                 listp
assoc                  listp
c...r                  consp
foreach                consp
last                   listp
length                 listp
mapcar                 listp
member                 consp
nth                    consp
vl-every               listp
vl-list->string        listp
vl-list-length         listp
vl-member-if           listp
vl-member-if-not       listp
vl-position            listp
vl-remove              listp
vl-remove-if           listp
vl-remove-if-not       listp
vl-some                listp
vl-sort                listp
vl-sort-i              consp

foreach, member, nth & vl-sort-i just don't seem to fit the pattern.

[andrew_nao]

Thanks CAB; I'm glad you find the reference useful Andrew 

its essential for me when i code, most times it helps me located where my errors are and what i did wrong.  i used to have a text file of them saved but i cant find it on my harddrive.

thanks for your time putting these together

[Lee Mac]

its essential for me when i code, most times it helps me located where my errors are and what i did wrong.  i used to have a text file of them saved but i cant find it on my harddrive.

thanks for your time putting these together

You're very welcome Andrew 

Regarding how to locate the source of an error, sometimes this can be trivial given the content of the error message, but for more elusive errors, I always resort to the method described in my tutorial here under the section 'Where did the Code Fail?'.

[irneb]

I always resort to the method described in my tutorial here under the section 'Where did the Code Fail?'.

Too true! I sometimes even ignore the error message and rather just use VLIDE to show me where the error happened - tends to give "me" more info about the error that way.

An old method of trying to get more info was to use the trace function. At least you could then read the command-line to determine which defun was called last when the error happened.

[Lee Mac]

An old method of trying to get more info was to use the trace function.

I agree - I use trace a lot when debugging recursive functions as the Trace window in the VLIDE will contain a log of each function evaluation, the supplied arguments and the returns of each evaluation.

[andrew_nao]

i do use that method sometimes, only when the routine isnt long.
most of my routines i work on involve some type of external file reading and writing, to and from and can sometimes take 20 mins to go thru the routine. so what i like to do is put most things in sub functions and call them. it makes it easy for me to see where i went wrong and what i did plus i get an education at the same time.

[CAB]

i do use that method sometimes, only when the routine isnt long.

Andrew,
You need to set break points so that you may step through only those sections of code you wish to.
The length of the routine should have no bearing on the debug method. 

[irneb]

The length of the routine should have no bearing on the debug method. 

Agreed. The trace function would only list the defun started, so if you only use trace - then you'd need to ensure your defuns are as simplistic / split as possible.

But VLIDE's other debug stuff is a lot more fine-grained and can show you each item inside the defun. Breakpoints are definitely the way to go. You can even use VLIDE's "Last Break Source" option (Ctrl+F9) as per Lee's tut to find out where inside the defun the error occurred - then set a breakpoint just before it and run your code again (open a watch window and inspect your variables' values to check if something has a value which it shouldn't).

I even use breakpoints + watch to figure out what's happening inside any defun. Sometimes its as simple as a variable name slightly misspelled or such.