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

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Oct 4 15:48:55 EDT 2010


please clean.
Use version management to control impact on other clients. Else we cannot move
and this is agony. slow and painful.

Stef

>> 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
> 
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project





More information about the Pharo-dev mailing list