Indeed people like to play with better API and sometimes this is not better. I prefer on:do: because like that I know that this is about Exception handling. Stef
Hi,
8. 1. 2016 v 17:11, Tudor Girba <tudor@tudorgirba.com>:
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 <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."