Hi,

8. 1. 2016 v 17:11, Tudor Girba <[email protected]>:

> Hi,
> 
> Denis says that right now, to use ifError: you do:
> 
> [...] ifError: [:msg :rcv | … ]
> 
> and he would like to write this:
> 
> [...] ifError: [:error | … ]

But for this we have on:do: message, right?
Do we need ifError:?

Cheers,
Juraj

> 
> I agree with him. The problem is that this might generate a bit of ripple 
> effects in external code. This is when Stephan came in and said that if we 
> would have a way to investigate all external repositories that are open we 
> could do such refactorings more boldly.
> 
> Does it make more sense now? Or did I get it wrong?
> 
> Cheers,
> Doru
> 
> 
> 
>> On Jan 8, 2016, at 10:05 PM, stepharo <[email protected]> wrote:
>> 
>> Hi denis
>> I do not understand the problem and I'm convinced that you are right 
>> so can anybody explain to me the point made by denis?
>> 
>> Stef
>> 
>> Le 7/1/16 13:11, Denis Kudriashov a écrit :
>>> Hi
>>> 
>>> I look at implementation of BlockClosure>>ifError: . I did't know that it 
>>> culls arguments to errorBlock. 
>>> But what is this arguments? It is not error instance but specific 
>>> properties from it.
>>> 
>>> BlockClosure>>ifError: errorHandlerBlock
>>> 
>>>    ^ self on: Error do: [:ex |
>>>        errorHandlerBlock cull: ex description cull: ex receiver]
>>> 
>>> Why people doing that?
>>> Many users of it just pass given error like 
>>> 
>>> [...] ifError: [:msg :rcv | ...
>>> rcv error: msg].
>>> 
>>> Especially it is commonly used scenario by senders of  #critical:ifError:. 
>>> But it is different question.
>>> 
>>> I propose change ifError: to cull error instance.
>>> 
>>> What you think? Can be put it in Pharo 5? Such change can touch some 
>>> packages
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Be rather willing to give than demanding to get."
> 
> 
> 
> 
> 

Reply via email to