How do i find the location of error: bad argument type: fixnump: nil

[stanovb]

What's the best way to find the cause of this error? From what I found online, "The error is caused by a function requiring an integer argument has been passed an argument of incorrect data type with the value noted in the error
message". The message I get is nil, but I don't know what part of the code this error is occurring at. I tried to break on error than ran the routine , but its still unclear to me where the error is at. Is there a better approach? Should I try the variable watch? I can post the code if someone needs to see it, but there are multiple routines that work together. I'm pretty sure which routine is causing the error, I just don't know how to locate where in the routine the error is occurring at.

[ВeekeeCZ]

See THIS recording.

It's a simple line that fails if no integer is entered - so I did and located the line.

Edit:

"but its still unclear to me where the error is at. "

what does this mean? Doesn't it show the line?

If you can post all components to be able to run and test it, please do.

[pbejse]

---

@stanovb wrote:

..t. I tried to break on error than ran the routine... 

---

You're spot on, [ assuming of course your on vlide ] and then after it stops , go to Debug/ Last Break Source [ Ctrl+9 ] That will tell you "where"  the error occur.

or

Use  Toggle Breakpoint on the part you think it breaks, the n use F8 [ Step into ] so you can "see" what happens every line.

HTH

EDIT:  What @ВeekeeCZ said 🙂 

I was too late with my reply. These **** Chicken wings!

[stanovb]

Break on last source tells what the error is but I don't see where it tells me the location. The are more than 3 lisp files so maybe i can zip them together & post that

[ВeekeeCZ]

Sure. Also post a test DWG and tell what values to enter to get your error.

[stanovb]

Here is the code

[stanovb]

sorry didn't see that part. the test drawing probable could be any drawing but here is our template file in dwg format. I'm not sure if it would work for anyone without the same directories & files

[ВeekeeCZ]

Ou, it's this project. You're right, not a chance.

You need to do what @pbejse suggests. Add multiple breakpoints at some relevant places, and run the code from one breakpoint to another until it fails... Then add more breakpoints in between... to locate the line.

Something like THIS 

[pbejse]

---

@stanovb wrote:

Break on last source tells what the error is but I don't see where it tells me the location. The are more than 3 lisp files so maybe i can zip them together & post that

---

Sure it does. and pressing ctrl+f9 will show you the location.

That is a LOT of code @stanovb.

Wow!  "McDONALDS"  That will be 2 Big Macs for me and Z9E3zK5E . and hold the mayo please.

Bet money @ВeekeeCZ will post a screencast video of the solution.

Anyone? anyone?

[ВeekeeCZ]

---

@pbejse wrote:

---

@stanovb wrote:

Break on last source tells what the error is but I don't see where it tells me the location. The are more than 3 lisp files so maybe i can zip them together & post that

---

Sure it does. and pressing ctrl+f9 will show you the location.

That is a LOT of code @stanovb.

Wow!  "McDONALDS"  That will be 2 Big Macs for me and Z9E3zK5E . and hold the mayo please.

Bet money @ВeekeeCZ will post a screencast video of the way to find a solution.

Anyone? anyone?

---

Yeah, youre right, that was the plan.

[john.uhden]

OR,

He could use the antediluvian Uhden Method of filling every other line of code with (setq ok #) where # is a manually increasing integer and ok is global.  So when the code craps out I check the value of ok and know that the trouble is in the line before that value.  I think the most oks I've ever used is around 30 in one command function.

[pbejse]

---

@john.uhden wrote:

...antediluvian Uhden Method

---

You just made that up @john.uhden !!! 😄

Try your hand at using  Toggle breakpoint + Step Into @stanovb , I'm sure you will get the hang of it.

[pbejse]

Oops. double posted!!

I will use this later if needed

--------------------------------

--------------------------------

---

[john.uhden]

@pbejse 

NO, I did not just make that up.  The word "antediluvian" has been around since The Great Flood.  :]

AND, I have seriously been using the Uhden Method since I can remember.  It's a habit.

I just don't remember who thought of it.  😉

[Sea-Haven]

Like John

Ms word use \p for end of line replace so could add a line value.

Replace ^p

^p(princ (strcat "\n" (rtos (setq x (1+ x)) 2 0)))^p

NOTE paste modified code into Notepad do not save direct from Word it can contain hidden characters.

Notepad++ if remember correct is \r for end of line.

[stanovb]

I will try this approach. I cannot seem to get it to show me where the problem is by using the break point but, I'm probably doing something wrong. I do need to learn how to use these features better. So you're saying add the ok value into the watch console?

[john.uhden]

No, I don't know anything about watch consoles.

Here's an example of what I do...

(defun c:test ( / a b c)
  (setq ok 0)
  (setq a (getreal "\nEnter Real: "))
  (setq ok 1)
  (setq b (getstring "\nEnter String: "))
  (setq ok 2)
  (setq c (* a b))
  (setq ok 3)
  (princ)
)

Command: TEST

Enter Real: 2.2

Enter String: 33
; error: bad argument type: numberp: "33"

Command:
Command: !ok 2

... which means it failed before ok was set to 3, which is obviously correct.

[Kent1Cooper]

A related and also prehistoric technique that I sometimes use is to un-localize the variables for testing, and have them all set to nil overtly at the beginning of the routine [rather than starting with no values as a result of being localized].  The approach, as used in your "program," would be:

(defun c:test () ; / a b c)
  (setq a nil b nil c nil)
  (setq a (getreal "\nEnter Real: "))
  (setq b (getstring "\nEnter String: "))
  (setq c (* a b))
  (princ)
)

Then the variables that got set successfully "survive" past the routine.  When you get an error, you can check the variables [type ! followed by each variable name in succession] until one of them returns nil.  Then you know it didn't get as far as setting that one successfully, which usually means the problem is in the setting of that one.

When the whole thing is working right, you just remove the red parts above.  That's a lot simpler than taking out all the separate 'ok' settings in the antediluvian method, but there's the disadvantage that you need to check variables by name individually until one fails.

[stanovb]

hmm. the variable doesn't seem to be changing. maybe I'm doing something wrong

[marko_ribar]

Marvelous explanation Kent...

To resume your approach...

I won't do at beginning : (setq a nil b nil c nil ... )

I'd rather do : (mapcar '(lambda ( %%% ) (if %%% (set %%% nil))) '(a b c d ... [copy+paste what's from localization here] )))

Then when it breaks : (vl-some '(lambda ( %%% ) (setq $$$ (if (not $$$) 0 (1+ $$$))) (null %%%)) (list a b c d ... [ -||- ] )))

Then to see which one is nil - probably cause of error like you explained : (nth $$$ '(a b c d ... [ -||- ] )) => you get for ex. : W meaning this varibable is the alien...