Ok, let's summarize: If an error occurs, the handler block is not evaluated, but attached to a new exception, that exception is raised. Then, the caller catches that exception, retrieves the handler block, does some more ballyhoo, and then runs the handler block.
Yes, the block mostly contains some code to that allows the user to fix the problem (like to show all references of a class to be removed, etc.).
And you get invited to this construction by these methods in RBAbstractCondition:
errorBlock     ^self errorBlockFor: false
errorBlockFor: aBoolean     ^nil
These methods (and subclass implementations) are used to retrieve the right block that caused the composite condition to fail.
We can clean it up on the next sprint, if you want :)
The implementation in RBCondition is fine, the problem is more the way how exceptions are used to pass the values. This mainly stems from the fact that exceptions evolved over the past 15 years and are no longer the same as the signals that were used when the refactoring code was originally written. Now of course it is difficult to change this code because there are various users out there that depend on it, e.g. OB, RefactoringBrowser, SmaCC, ... Lukas -- Lukas Renggli www.lukas-renggli.ch