Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
FAQ: Breakpoints
Last updated at 6:04 am UTC on 30 November 2020
Is it possible to set breakpoints or watch conditions in Squeak?

Yes. One can set breakpoints or open inspectors on the fly in Squeak. Breakpoints or Watchpoints may be unconditional, conditional or triggered by a counter. These methods are found in the 'debugging' and 'debugging-haltOnce' categories of Object.

Simplest

In the message list of the browser, the menu has an entry 'toggle break on entry' about 1/3rd down. This quickly recompiles the method with a 'self break' as the first line. BUT this is an actual recompile - not like the inserted breakpoint in VW. You MUST remove it manually by either using the 'toggle...' menu item again, or manually editing the code to remove it. It's not super sophisticated and you can confuse things to end up with several 'self break' lines in your code.

Very direct

Manually send #break or #halt (to any object) in your code.
self halt

More cleverer

Use #halt: or #haltIf:
Send #halt: {some String} to open a debugger and include a hopefully useful error string.
self halt:'this should not happen. Help'

Really clever

Send #haltIf: with either aSymbol or a Block. This is pretty clever stuff.

Simple clever use -

 foo haltIf: #thingy

This will open a debugger IFF the #thingy symbol is in the call stack - ie if someone has sent #thingy in the direct line of how you got here. Say you have a method to write a file but it gets used from two different routes. You can put a self haltIf: #wibble in the file writing method and only get a debugger if the route includes something sending #wibble.

More complicated use -

foo haltIf: [:me| me hasBrokenLeg]

Only opens a debugger if the block evaluates to true. Arbitrary code is allowed in the block, so be careful; you can have a block with no argu,ents, or one - which will be the receiver of the haltIf:.

#haltOnce and #inspectOnce

There's a whole stack of methods built around #haltOnce: You can send a #haltOnce and so long as you have enabled the haltOnce system it will ... halt... once. Duh. There's a variant to #haltOnCount: which will startle you by halting on the count'th time. The #inspectOnce group of methods open an inspector rather than a debugger.
To enable the haltOnce system you have to send #setHaltOnce to any object to turn it on each time It automatically turns off when triggered (otherwise it wouldn't halt just once). There is a convenient World menu entry (in the debug submenu) to enable it or disable it.
Loads more details if you look at Object 'debugging-haltOnce' protocol. There's also some versions to open an inspector on the trigger.
When dealing with morphic, it is usually better to use "self haltOnce" or "anInstance inspectOnce" which, if it gets called more than once, only pops up one debugger or inspector. Most things in morphic get called repeatedly, since there is a global event loop. This can result in a crashing image by putting it in a loop like this accidentally, resulting in infinite debugger windows.
See also Debugger