[Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

Lukas Renggli renggli at gmail.com
Mon Oct 4 10:34:18 EDT 2010


> 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




More information about the Pharo-dev mailing list