I don't think you can compare #halt with Breakpoints. Breakpoints
have two main advantages over halts:
They do not change source code, so there is no diff between
a method version with and without this debugging aid. Helps a
lot, especially in times when you urgenztly need to fix a bug
in production code. There's no time to read diffs that
baiscally have zero meaning saturday nights at 2:00 AM...
They cannot easily be packaged into the production/runtime
image, because they are not part of the source code. Thus it
cannot be "forgotten" when you deploy.
This is not relevant in Pharo, where there is no packaging
step as in VW or VAST, but there it really is. A halt in
production code makes for a great monday morning when the new
version was just shipped ;-)
So when you work on code to actually ship into users' hands, there
are quite some good arguments for Breakpoints. There's more to
them, like conditional Breakpoints that make debugging a bug so
much easier and Watchpoints, but these would make my message way
Of course all of the above-mentioned things can be achieved using
appropriate handlers for #halt and add stuff to them or make
#halts just ignored at deployment time, but these are also steps
that can be forgotten...
self selectedMethod: method. self updateCategoryAndMethodList ]] ifFalse: [self updateCategoryAndMethodList ] "<<< If compiled method changed, we do not call forceSelectMethod, which would reset the icon styler"