Smalltalk › Pharo › Pharo Smalltalk Developers

ifError: implementation is bad

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

Denis Kudriashov

ifError: implementation is bad

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

Sven Van Caekenberghe-2

Re: ifError: implementation is bad

> On 07 Jan 2016, at 13:11, Denis Kudriashov <[hidden email]> wrote:
>
> 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

If think it makes more sense to #cull: the exception instance, it is more object oriented. And it is what I would expect.

Denis Kudriashov

Re: ifError: implementation is bad

2016-01-07 13:35 GMT+01:00 Sven Van Caekenberghe <[hidden email]>:

If think it makes more sense to #cull: the exception instance, it is more object oriented

We all know it. But then we found such methods in the system and cry :). who can wrote it

Stephan Eggermont-3

Re: ifError: implementation is bad

In reply to this post by Denis Kudriashov

On 07-01-16 13:11, Denis Kudriashov wrote:
> What you think? Can be put it in Pharo 5? Such change can touch some
> packages

This is exactly why I want a compact archive representation of all
source code in the repos. Then we know what's touched.

Stephan

stepharo

Re: ifError: implementation is bad

In reply to this post by Denis Kudriashov

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

stepharo

Re: ifError: implementation is bad

In reply to this post by Denis Kudriashov

In general I do not like cull: and I'm really suspicious about its use.
It often reveals a lack of coherence and/or design.
Why this is not simply

BlockClosure>>ifError: errorHandlerBlock

^ self on: Error do: errorHandlerBlock

??

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

Tudor Girba-2

Re: ifError: implementation is bad

In reply to this post by stepharo

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 <[hidden email]> 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."

Juraj Kubelka

Re: ifError: implementation is bad

Hi,

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

> 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 <[hidden email]> 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."
>
>
>
>
>

stepharo

Re: ifError: implementation is bad

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 <[hidden email]>:
>
>> 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 <[hidden email]> 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."
>>
>>
>>
>>
>>
>

Denis Kudriashov

Re: ifError: implementation is bad

In reply to this post by Tudor Girba-2

2016-01-08 21:11 GMT+01:00 Tudor Girba <[hidden email]>:

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?

Exactly Tudor.

My cry was about why man who implement it decides to deincapsulate error state.

Denis Kudriashov

Re: ifError: implementation is bad

In reply to this post by Juraj Kubelka

2016-01-08 21:17 GMT+01:00 Juraj Kubelka <[hidden email]>:

Hi,

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

> 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:?

It is nice convenient method for the case when you don't care what exact error happens. It is very useful for scripting.

sum := 0.

#(1 asd 4534 5423 sdfs) do: [:each | [sum := sum + each] ifError: []]

Actually I never use argument version of block. But it definitely should be error instance and not of one of it properties.

Denis Kudriashov

Re: ifError: implementation is bad

In reply to this post by stepharo

2016-01-08 21:30 GMT+01:00 stepharo <[hidden email]>:

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.

But it is too long. ifError: is very intuitive name.

stepharo

Re: ifError: implementation is bad

> But it is too long. ifError: is very intuitive name.
Not to me.

Stef

stepharo

Re: ifError: implementation is bad

In reply to this post by Denis Kudriashov

>
> 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
So did you fix it?

Stef

Denis Kudriashov

Re: ifError: implementation is bad

2016-01-10 21:29 GMT+01:00 stepharo <[hidden email]>:

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

So did you fix it?

Not yet. I will do this when other my changes on Kernel will be integrated. It gives me thoughts that Kernel should be splitter on small packages

stepharo

Re: ifError: implementation is bad

What you think? Can be put it in Pharo 5? Such change can touch some packages

So did you fix it?

Not yet. I will do this when other my changes on Kernel will be integrated. It gives me thoughts that Kernel should be splitter on small packages

totally agreed :)

Guillermo Polito

Re: ifError: implementation is bad

In reply to this post by Denis Kudriashov

On 11 ene 2016, at 2:19 p.m., Denis Kudriashov <[hidden email]> wrote:

2016-01-10 21:29 GMT+01:00 stepharo <[hidden email]>:
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

So did you fix it?

Not yet. I will do this when other my changes on Kernel will be integrated. It gives me thoughts that Kernel should be splitter on small packages

+1111^1111111

We should make a list. Some that should be easy:

- Delay should be splitted

- Chronology should be splitted

One more complicated:

- InstructionClient and InstructionStream should be splitted

And then, we should also review the API of basic objects

Object methods size => 385

Integer methods size => 182

...

Ben Coman

Re: ifError: implementation is bad

On Mon, Jan 11, 2016 at 11:52 PM, Guillermo Polito
<[hidden email]> wrote:

>
> On 11 ene 2016, at 2:19 p.m., Denis Kudriashov <[hidden email]> wrote:
>
>
> 2016-01-10 21:29 GMT+01:00 stepharo <[hidden email]>:
>>>
>>> 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
>>
>> So did you fix it?
>
>
> Not yet. I will do this when other my changes on Kernel will be integrated.
> It gives me thoughts that Kernel should be splitter on small packages
>
> +1111^1111111
>
> We should make a list. Some that should be easy:
>
> - Delay should be splitted

I'll do Delay. I'm in the middle of cleaning it bit atm.
https://pharo.fogbugz.com/default.asp?17375

cheers -ben

> - Chronology should be splitted
>
> One more complicated:
>
> - InstructionClient and InstructionStream should be splitted
>
> And then, we should also review the API of basic objects
>
> Object methods size => 385
> Integer methods size => 182
> ...

stepharo

Re: ifError: implementation is bad

In reply to this post by Guillermo Polito

+1111^1111111
>
> We should make a list. Some that should be easy:
>
> - Delay should be splitted
why?

Guillermo Polito

Re: ifError: implementation is bad

> On 12 ene 2016, at 8:53 p.m., stepharo <[hidden email]> wrote:
>
>
> +1111^1111111
>>
>> We should make a list. Some that should be easy:
>>
>> - Delay should be splitted
> why?

First, I mean Delay, not processes. Processes are required for executing code, delays are not. I believe that Delay is not a language kernel concern. It is an important concern but not a Kernel one.
Also,
- the biggest it is the Kernel package, the more difficult it is to analyze dependencies (because everything depends on kernel so who would care, no?)
- I could imagine little images that do not contain delay, because they do not use it. Of course, it is not the typical Pharo distribution but it is a possible case.

I only say that having it in a separate package is worth it. Check senders of wait, you will see that the usages inside the kernel are really few: mainly BlockClosures implementing things like #valueAndWait and Delay tests.

>
>> - Chronology should be splitted
>>
>> One more complicated:
>>
>> - InstructionClient and InstructionStream should be splitted
>>
>> And then, we should also review the API of basic objects
>>
>> Object methods size => 385
>> Integer methods size => 182
>> ...
>
>