How to Properly Handle Script Debugging in Script Debugger 8

AppleScript
#1

Hey guys… :wave:

I have Script Debugger 8 and have been exploring its features for automating tasks with AppleScript. One area where I’m struggling a bit is with debugging. I’ve seen the various debugging tools like breakpoints, step execution, and variable inspection, but I feel like I’m not using them to their full potential.

Could someone explain how to efficiently use the debugging tools in Script Debugger? For instance, how do you decide where to place breakpoints, and how do you approach stepping through scripts without getting overwhelmed by all the details? I often find myself losing track of which part of the script I’m debugging, especially when dealing with more complex scripts with many handlers and variables.

Could anyone guide me about this? Additionally, are there any best practices or tips for reading through the log or for managing multiple scripts at once? Sometimes I find it hard to interpret the logs effectively when errors or unexpected behavior occur.

Thanks in advance!

Respected community member! :smiling_face_with_three_hearts:

#2

First thing is that the Debugging in Script Debugger is ideally suited for breaking the work in your script in handlers.

I place breakpoints on the fly, where I expect an issue to show itself. Nearly apple event or command returns a result, so I place breakpoints after a specific command so I can see the result in the result pane,

Sometimes I’ll just put the name of a variable or a simple command on a line by itself and a breakpoint on the next line so I can see it’s value before the script goes on to use it. (This is often useful with local variables inside handlers, but you can also declare local variable in the handler and see their value.)

Also there is a page here with links to a number of short videos, tutorials and guidance for debugging with Script Debugger, which are very worthwhile. I particularly like the feature in <20 Seconds video.

#3

I place breakpoints on a need to know basis.
Suppose I have just made some changes to a script - usually I will do some test runs witt the debugger off. If no errors, I’m done.

If it crashes, I will turn on debug mode, and put a breakpoint just before where it crashes, run the script again and check out the variables used on the line of the crash to understand the reason for the crash.

If there is a big record, list or string involved, then I open an explorer window for that variable(s).

Then I manually step thru the line of the crash itself, and observe the crash again. Sometimes it doesn’t crash because there may be multiple instances where that part of the code is executed, and it only crashes on some of those, so you have to continue executing until the breakpoint is encountered again, until you find the instance of the crash. If you come to realise that the crash only happens when A=6 for example, you can edit the breakpoint to only trigger when A=6

OK, so now you know what happened at the crash itself.

But now the question is usually “How did the variables get into that state?”

If the answer isn’t immediately obvious, my next step is usually to put another breakpoint at the beginning of the handler where the crash occured, run the script, check if the variable states are as expected at beginning of the handler.

If the state at the handler entry is as expected, I will step manually line by line to observe how things went wrong, If its a long handler, and some of the code can obviously be ignored, then right click on an intermediate line, and select “Execute to here”.

If on the other hand, the state at the handler entry is not as expected, the next question is “how did the call to the handler go wrong”

To understand this, first check the hierarchy of handlers in the right hand window. Now the autostepping function can be used to check if the sequence of handler calls is as expected.

Then I will put a breakpoints before every line where the problem handler is called, and use this to discover how the handler call went wrong.

1 Like