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

Lukas Renggli renggli at gmail.com
Mon Oct 4 10:14:56 EDT 2010


The tool that triggers the refactoring, e.g. ORCommand>>#handleError:

Ok, the code is quite ugly, but this is how the original refactoring
browser implemented it.

On 4 October 2010 16:06, Niko Schwarz <niko.schwarz at googlemail.com> wrote:
> Ok, help me out, how is that block ever invoked? The above code
> snippet just appends the block as a parameter to an exception, which
> looks just funny.
>
> Niko
>
> On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli <renggli at gmail.com> wrote:
>> See for senders of #errorBlock:, e.g.
>> PushDownInstanceVariableRefactoring, RemoveClassRefactoring or
>> RemoveInstanceRefactoring.
>>
>> On 4 October 2010 15:40, Lukas Renggli <renggli at gmail.com> wrote:
>>> This is used to validate the preconditions of refactorings and inform
>>> the user about any mismatches.
>>>
>>> It should better not be removed.
>>>
>>> Lukas
>>>
>>> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz at googlemail.com> wrote:
>>>> Hi,
>>>>
>>>> The RB refactorings do some obscure dance around an errorBlock, which
>>>> is always nil, as far as I can see. As I was trying to supply a
>>>> non-nil error block, I was astonished to find out that even if it
>>>> isn't nil, it won't be executed. Here's the relevant snippets:
>>>>
>>>> checkPreconditions
>>>>        | conditions block |
>>>>        conditions := self preconditions.
>>>>        conditions check
>>>>                ifFalse:
>>>>                        [block := conditions errorBlock.
>>>>                        block notNil
>>>>                                ifTrue: [self refactoringError: conditions errorString with: block]
>>>>                                ifFalse: [self refactoringError: conditions errorString]]
>>>>
>>>> refactoringError: aString with: aBlock
>>>>        ^ RefactoringError signal: aString with: aBlock
>>>>
>>>> I can't imagine how that could help anyone. I suggest either removing
>>>> the errorBlock, or turning it into a good old instance variable, and
>>>> running it in case of an error.
>>>>
>>>> Cheers,
>>>>
>>>> Niko
>>>>
>>>> --
>>>> http://scg.unibe.ch/staff/Schwarz
>>>> twitter.com/nes1983
>>>> Tel: +41 076 235 8683
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project at lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> http://scg.unibe.ch/staff/Schwarz
> twitter.com/nes1983
> Tel: +41 076 235 8683
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Lukas Renggli
www.lukas-renggli.ch




More information about the Pharo-dev mailing list