[Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock
stephane.ducasse at inria.fr
Mon Oct 4 15:48:55 EDT 2010
Use version management to control impact on other clients. Else we cannot move
and this is agony. slow and painful.
>> 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,
>> And you get invited to this construction by these methods in
>> ^self errorBlockFor: false
>> errorBlockFor: aBoolean
> 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 Renggli
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev