[Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock
niko.schwarz at googlemail.com
Mon Oct 4 10:06:43 EDT 2010
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.
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
> 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.
>> On 4 October 2010 15:36, Niko Schwarz <niko.schwarz at googlemail.com> wrote:
>>> 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:
>>> | conditions block |
>>> conditions := self preconditions.
>>> conditions check
>>> [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.
>>> Tel: +41 076 235 8683
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Lukas Renggli
> Lukas Renggli
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Tel: +41 076 235 8683
More information about the Pharo-dev