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 <steph...@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."
