It Worked the First Time! Why Does My SKILL Code Fail on the Second Run?

Have you ever run a SKILL function successfully, only to find that running it again produces an error or unexpected behaviour?

One common cause is that the first execution changes the database or application state that the code assumes will still be available on the next run. For example, your code may keep references to database objects that have since been deleted, replaced, or modified.

A useful troubleshooting technique is to avoid relying on database object IDs stored globally between executions. Instead, retrieve the objects you need each time the function runs and validate the returned values before operating on them.

For instance:

procedure(processSelectedObject()
  let((obj)

    obj = car(axlGetSelSet())

    if(obj then
      printf("Current object: %L\n" obj)
      ; Process obj here
    else
      printf("No object is currently selected.\n")
    )
  )
)

Database objects aren't the only thing to consider. A SKILL script can also change session state such as the current selection or Find Filter. If your function depends on a particular state, the second execution may start under different conditions than the first.

When debugging this kind of problem, try this approach:

1. Run the function once.
2. Check what changed in the design or session.
3. Run it again and identify the first operation that behaves differently.
4. Add printf() statements around your operations.
5. Inspect database objects and return values instead of assuming they are valid.
6. Where appropriate, reacquire database objects rather than relying on references retained from an earlier execution.

These steps are crucial specially when you're testing loose SKILL commands, where moving the canvas, zooming in or modifying the position of the elements might change the dbIDs of the objects.