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 <[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."
