Hi, Denis says that right now, to use ifError: you do: [...] ifError: [:msg :rcv | ⦠] and he would like to write this: [...] ifError: [:error | ⦠] 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 <stepharo@free.fr> 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."