Smalltalk › Pharo › Pharo Smalltalk Developers

Catching Exceptions without any notice

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

35 messages Options

Igor Stasenko

Re: Catching Exceptions without any notice

On 2 April 2016 at 01:13, Henrik Nergaard <[hidden email]> wrote:

>Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late initialized objects. For example, imagine a Morph with height that is equal to >owner's height. In this case one would write in #initialize:

>Initialize

> self height: [ :morph | morph owner height ].

No.

ownerChanged

self height: owner height.

…………..

One should not rely on the owner being set during initialization (90% of the time at least), it makes morphs too reliant on certain cases, which makes them harder to use/understand.

If the morph must have an owner to operate properly, it loses many of its abilities such as being its own root, for example to make images.

ThatMorph new exportAsPng.

Amen. Simply avoid using objects in incomplete state to prevent errors like we see in this topic. That means, you should not mess with object's properties until it is fully initialized, that's what #initialize for.
If you have coupling and chicken and egg problem like parent/child relationship - you shall again make sure nobody accessing that couple from outside while it is still in inconsistent state, and then once it is fully initialized - you don't need to guard against silly nil errors, because everything is set up.
And in that couple, you can split things on stages, making sure that on initial stage, you again don't use/access not yet initialized properties.

You need a plan, to be able to not put cart in front of the horse and that is much better than putting it that way and then trying to deal with it in a way like on-do-nothing pattern.

Once again, one way or another - you don't need to use on-do-nothing, if you doing things right. And if you need it - then that indicates that you got a problem, and instead of solving and fixing it, you bury it under "catch-all and shut-up" gravestone :)

Best regards,

Henrik

Best regards,
Igor Stasenko.

Igor Stasenko

Re: Catching Exceptions without any notice

In reply to this post by Tudor Girba-2

On 2 April 2016 at 01:07, Tudor Girba <[hidden email]> wrote:

Hi Igor,

You are more than welcome to come back.

Thank you.

Too much acidity is good neither for you nor for the people around you :). Let’s be kind with one another and assume that we all care and we want to make this world a better place, but that at the same time we are still only humans.

Arguable. Sometimes "Purge the heretics" tactic works better to teach people to not make code smells. Sometimes don't. :)
In any case, i never target personalities, if you know me, i only target bad, smelly code. Yeah, i maybe overreacting and using harsh wording.. But that just to underscore my attitude towards the subject.. but never towards people.
Because i know, most of people that contributing here having good intentions, so there's no point to do any personal attacks.

Cheers,
Doru

> On Apr 1, 2016, at 10:51 PM, Igor Stasenko <[hidden email]> wrote:
>
>
>
> On 1 April 2016 at 09:53, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> Nice to hear from you Igor. I am glad to see you around here.
>
> Hi, Doru. Yeah, i am considering whether i want to return to things i left, or not. So, expect more of my acid sarcasm in future. Maybe :)
>
> I do not see how your quote applies to the current case given that the original authors did not leave anywhere, but perhaps it was a joke, and I did not get it.
>
> We all will leave sooner or later. The only what matters is what we left behind :)
>
> Cheers,
> Doru
>
>
> > On Apr 1, 2016, at 5:54 AM, Igor Stasenko <[hidden email]> wrote:
> >
> > A perfect example of careless programming.
> > "I'll do it my way, and if it causing any problems, i don't care and i will just ignore them. And it's not my problem anyways, i went to something else already, since this part is works and DONE"
> > :)
> >
> > On 30 March 2016 at 14:33, Nicolai Hess <[hidden email]> wrote:
> > Please don't do this:
> >
> > updateHeight
> > "no need to care about height, when it's logic is not customized"
> > self layout isHeightCustom ifFalse: [ ^ self ].
> > [ self bounds: (self brickBounds withHeight: self customHeight) ]
> > on: Exception
> > do: [ "just skip and do nothing" ]
> >
> > This makes debugging GLM/Brick ui/layout code with "self haltOnce" impossible.
> > see
> > GLMBrickGeometryTrait>>#updateHeight
> > GLMBrickGeometryTrait>>#updateWidth
> >
> > And if you log out the raised exception, you see some calls to
> > not initialized fonts and a ZeroDevide and some more errors.
> > The above catch, catches and hides wrong / to late initialized objects.
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko.
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>
>
>
>
>
>
> --
> Best regards,
> Igor Stasenko.

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."

Best regards,
Igor Stasenko.

Igor Stasenko

Re: Catching Exceptions without any notice

In reply to this post by Igor Stasenko

Another approach would be to prefill the object with initial default values, so that it has no any inconsistency right from its birth. Even if your next statement has 99.9% chance to override these defaults, you eliminating this 0.01% that causing nil errors. That, of course, raising another problem - that you might be dealing with 'wrong' initial state, but it is much less harmful than dealing with nils popping out of nowhere.

On 2 April 2016 at 02:20, Igor Stasenko <[hidden email]> wrote:

On 2 April 2016 at 01:13, Henrik Nergaard <[hidden email]> wrote:

>Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late initialized objects. For example, imagine a Morph with height that is equal to >owner's height. In this case one would write in #initialize:

>Initialize

> self height: [ :morph | morph owner height ].

No.

ownerChanged

self height: owner height.

…………..

One should not rely on the owner being set during initialization (90% of the time at least), it makes morphs too reliant on certain cases, which makes them harder to use/understand.

If the morph must have an owner to operate properly, it loses many of its abilities such as being its own root, for example to make images.

ThatMorph new exportAsPng.

Amen. Simply avoid using objects in incomplete state to prevent errors like we see in this topic. That means, you should not mess with object's properties until it is fully initialized, that's what #initialize for.
If you have coupling and chicken and egg problem like parent/child relationship - you shall again make sure nobody accessing that couple from outside while it is still in inconsistent state, and then once it is fully initialized - you don't need to guard against silly nil errors, because everything is set up.
And in that couple, you can split things on stages, making sure that on initial stage, you again don't use/access not yet initialized properties.
You need a plan, to be able to not put cart in front of the horse and that is much better than putting it that way and then trying to deal with it in a way like on-do-nothing pattern.

Once again, one way or another - you don't need to use on-do-nothing, if you doing things right. And if you need it - then that indicates that you got a problem, and instead of solving and fixing it, you bury it under "catch-all and shut-up" gravestone :)

Best regards,

Henrik

--
Best regards,
Igor Stasenko.

Best regards,
Igor Stasenko.

Robert Withers

Re: Catching Exceptions without any notice

Good to see you again, Igor. Would it make sense to define instVar initializers in the class object allowing the install of init forwarders in the object slots on VM for a Squeak-style implicitly typed dependency injection? Welcome.

---

robert

On Apr 1, 2016, at 19:48, Igor Stasenko <[hidden email]> wrote:

Another approach would be to prefill the object with initial default values, so that it has no any inconsistency right from its birth. Even if your next statement has 99.9% chance to override these defaults, you eliminating this 0.01% that causing nil errors. That, of course, raising another problem - that you might be dealing with 'wrong' initial state, but it is much less harmful than dealing with nils popping out of nowhere.

On 2 April 2016 at 02:20, Igor Stasenko <[hidden email]> wrote:

On 2 April 2016 at 01:13, Henrik Nergaard <[hidden email]> wrote:

>Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late initialized objects. For example, imagine a Morph with height that is equal to >owner's height. In this case one would write in #initialize:

>Initialize

> self height: [ :morph | morph owner height ].

No.

ownerChanged

self height: owner height.

…………..

One should not rely on the owner being set during initialization (90% of the time at least), it makes morphs too reliant on certain cases, which makes them harder to use/understand.

If the morph must have an owner to operate properly, it loses many of its abilities such as being its own root, for example to make images.

ThatMorph new exportAsPng.

Amen. Simply avoid using objects in incomplete state to prevent errors like we see in this topic. That means, you should not mess with object's properties until it is fully initialized, that's what #initialize for.
If you have coupling and chicken and egg problem like parent/child relationship - you shall again make sure nobody accessing that couple from outside while it is still in inconsistent state, and then once it is fully initialized - you don't need to guard against silly nil errors, because everything is set up.
And in that couple, you can split things on stages, making sure that on initial stage, you again don't use/access not yet initialized properties.
You need a plan, to be able to not put cart in front of the horse and that is much better than putting it that way and then trying to deal with it in a way like on-do-nothing pattern.

Once again, one way or another - you don't need to use on-do-nothing, if you doing things right. And if you need it - then that indicates that you got a problem, and instead of solving and fixing it, you bury it under "catch-all and shut-up" gravestone :)

Best regards,

Henrik

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

Igor Stasenko

Re: Catching Exceptions without any notice

On 2 April 2016 at 03:06, Robert Withers <[hidden email]> wrote:

Good to see you again, Igor. Would it make sense to define instVar initializers in the class object allowing the install of init forwarders in the object slots on VM for a Squeak-style implicitly typed dependency injection? Welcome.

I would certainly recommend to construct objects prefilled with sane defaults, especially taking advantage of having extra niceties from VM, and especially when it about UI domain, where insane complexity knocking to your doors right from the beginning.

But alas, due to inherent nature of UI that tends to be complex, often you need to generate a whole subgraph of objects, and therefore you are limited in choice: basically you have to carefully design a multi-stage initialization procedure, sorting out all chickens and their eggs, before giving things away for later use.
That is doable and once you define in your object soup who gonna make a first move, you defining the order of initialization and consequently the constraints of being able to access certain properties during partial initialization or not.
Else, if you not define any constraints, and let things grow naturally, sure you will end up using on-do-nothing more and more often, up to the point that you find youself unable to initialize any object without taking 'advantage' provided by such pattern. :)

---
robert

On Apr 1, 2016, at 19:48, Igor Stasenko <[hidden email]> wrote:

Another approach would be to prefill the object with initial default values, so that it has no any inconsistency right from its birth. Even if your next statement has 99.9% chance to override these defaults, you eliminating this 0.01% that causing nil errors. That, of course, raising another problem - that you might be dealing with 'wrong' initial state, but it is much less harmful than dealing with nils popping out of nowhere.

On 2 April 2016 at 02:20, Igor Stasenko <[hidden email]> wrote:

On 2 April 2016 at 01:13, Henrik Nergaard <[hidden email]> wrote:

>Purpose of that catch, as mentioned by Nicolai, is indeed to ignore late initialized objects. For example, imagine a Morph with height that is equal to >owner's height. In this case one would write in #initialize:

>Initialize

> self height: [ :morph | morph owner height ].

No.

ownerChanged

self height: owner height.

…………..

One should not rely on the owner being set during initialization (90% of the time at least), it makes morphs too reliant on certain cases, which makes them harder to use/understand.

If the morph must have an owner to operate properly, it loses many of its abilities such as being its own root, for example to make images.

ThatMorph new exportAsPng.

Amen. Simply avoid using objects in incomplete state to prevent errors like we see in this topic. That means, you should not mess with object's properties until it is fully initialized, that's what #initialize for.
If you have coupling and chicken and egg problem like parent/child relationship - you shall again make sure nobody accessing that couple from outside while it is still in inconsistent state, and then once it is fully initialized - you don't need to guard against silly nil errors, because everything is set up.
And in that couple, you can split things on stages, making sure that on initial stage, you again don't use/access not yet initialized properties.
You need a plan, to be able to not put cart in front of the horse and that is much better than putting it that way and then trying to deal with it in a way like on-do-nothing pattern.

Once again, one way or another - you don't need to use on-do-nothing, if you doing things right. And if you need it - then that indicates that you got a problem, and instead of solving and fixing it, you bury it under "catch-all and shut-up" gravestone :)

Best regards,

Henrik

--
Best regards,
Igor Stasenko.

--
Best regards,
Igor Stasenko.

Best regards,
Igor Stasenko.

stepharo

Re: Catching Exceptions without any notice

In reply to this post by Igor Stasenko

Igor please use your energy helping us.

Stef

Le 1/4/16 22:47, Igor Stasenko a écrit :

On 1 April 2016 at 21:52, stepharo <[hidden email]> wrote:

Hi

I do not think that aliaksei is not taking care.
He is working a lot to make sure that Pharo will have a future from the UI perspective. He is spending all his free time
on Bloc and what he is doing is massive. He rewrote the AthensCairoBack end to optimise it for Bloc local coordinates.
I'm sure that if someone would have propose some help to him he would have gladly accepted.

I personnaly thank him for all the energy that he is putting into Bloc. The talk at PharoDays was showing really nice results.
Bloc is really getting to be really nice and change the face of Pharo for the next decades so we should encourage people doing
Bloc!

So instead of bashing someone, I would prefer that we help him.
Yes Pharo has some code that we do not like and I have my own list. Now the best things to do is to
improve code review and to fix when we see something wrong.

Hi, Stef. No, it is not about whether you care about things you do or not. It is about approach. If you done something, that good indication that you care about it, isn't? But there's many ways how you doing something.

I am sorry, i won't stop bashing approaches like this piece of code demonstrating. It was not a first time you seen my reaction on such piece of code (we seen that before, exactly related to "on:do: nothing" before), and i don't think you shall be surprised that my reaction is unchanged :)

My take on this: on-do-nothing pattern is good only for one thing: for bug hunting and putting temporary kludges in code in order to find the root of problem. Once problem is solved, you shall remove this.. as well as any 'Transcript show:' , 'Halt once' and stuff like that.
On-do-nothing really don't belongs to category of any production code that pretends to be a good quality one.

Stef

Le 1/4/16 05:54, Igor Stasenko a écrit :

A perfect example of careless programming.
"I'll do it my way, and if it causing any problems, i don't care and i will just ignore them. And it's not my problem anyways, i went to something else already, since this part is works and DONE"
:)

On 30 March 2016 at 14:33, Nicolai Hess <[hidden email]> wrote:

Please don't do this:

updateHeight
    "no need to care about height, when it's logic is not customized"
    self layout isHeightCustom ifFalse: [ ^ self ].
    [ self bounds: (self brickBounds withHeight: self customHeight) ]
        on: Exception
        do: [ "just skip and do nothing" ]

This makes debugging GLM/Brick ui/layout code with "self haltOnce" impossible.
see
GLMBrickGeometryTrait>>#updateHeight
GLMBrickGeometryTrait>>#updateWidth

And if you log out the raised exception, you see some calls to

not initialized fonts and a ZeroDevide and some more errors.

The above catch, catches and hides wrong / to late initialized objects.

--

Best regards,
Igor Stasenko.

--

Best regards,
Igor Stasenko.

stepharo

Re: Catching Exceptions without any notice

In reply to this post by Tudor Girba-2

philippeback

Re: Catching Exceptions without any notice

"Used for centuries to preserve meat and fish, citric acid has innumerable health benefits. It increases the acidity of the bacterial environment, making it difficult for the microbes to survive and, more importantly, to reproduce."

Applies to bugs and code smells.

Phil

On Sat, Apr 2, 2016 at 11:45 AM, stepharo <[hidden email]> wrote:

Hi Igor,

You are more than welcome to come back.

Too much acidity is good neither for you nor for the people around you :). Let’s be kind with one another and assume that we all care and we want to make this world a better place, but that at the same time we are still only humans.

+1
Especially since aliaksei took all the remarks I did on his code and he is asking for feedback.

Stef

Igor Stasenko

Re: Catching Exceptions without any notice

In reply to this post by stepharo

On 2 April 2016 at 12:45, stepharo <[hidden email]> wrote:

Hi Igor,

You are more than welcome to come back.

Too much acidity is good neither for you nor for the people around you :). Let’s be kind with one another and assume that we all care and we want to make this world a better place, but that at the same time we are still only humans.

+1
Especially since aliaksei took all the remarks I did on his code and he is asking for feedback.

Perfect. You working with a person who can accept and learn from criticism.. What on earth can be better than that? And if my 5 cents of acid helped to convince him, that's only makes me feel accomplished my mission :)

(No pun and sarcasm intended).

Stef

Best regards,
Igor Stasenko.

Igor Stasenko

Re: Catching Exceptions without any notice

In reply to this post by stepharo

On 2 April 2016 at 12:44, stepharo <[hidden email]> wrote:

Igor please use your energy helping us.

I did not expected such a warm welcome and being in vain for more than a year..

Thank you all guys, you are great!

Yes, as i said i feel like i want to get some involvement.. So expect more acid in future, because that is my energy taking such unordinary form sometimes :)

Stef

Best regards,
Igor Stasenko.

Robert Withers

Re: Catching Exceptions without any notice

In reply to this post by Aliaksei Syrel

On 04/01/2016 05:40 PM, Aliaksei Syrel wrote:
>
> Thanks for feedback :)
>
> Nevertheless, later I realized that blocks are evil, ...

One touch of a block of evil :)

https://www.youtube.com/watch?v=Fw9IqUgGlzs

--
Robert
. .. ... ^,^

Igor Stasenko

Re: Catching Exceptions without any notice

On 2 April 2016 at 14:13, Robert Withers <[hidden email]> wrote:

On 04/01/2016 05:40 PM, Aliaksei Syrel wrote:

Thanks for feedback :)

Nevertheless, later I realized that blocks are evil, ...

btw, why so?

One touch of a block of evil :)

https://www.youtube.com/watch?v=Fw9IqUgGlzs

--
Robert
. .. ... ^,^

Best regards,
Igor Stasenko.

stepharo

Re: Catching Exceptions without any notice

In reply to this post by Igor Stasenko

> I did not expected such a warm welcome and being in vain for more than
> a year..
> Thank you all guys, you are great!
>
> Yes, as i said i feel like i want to get some involvement.. So expect
> more acid in future, because that is my energy taking such unordinary
> form sometimes :)

I'm really happy for you.
If you can help with the SDL 20 integration. I'm not sure that
everything you did in last year may was integrated. In fact we did not
have the time
because of Spur and uFFI. In Pharo 60 we need to remove all the old
event chain and only use OSWindows.

Ronie will arrive a5 of April to Lille and he wants to work on Woden but
also it would be good to have his FFI (with special bytecode) integrated
into the JIT
so I imagine that clement, eliot, esteban and ronie should talk.

Stef

Igor Stasenko

Re: Catching Exceptions without any notice

On 2 April 2016 at 17:31, stepharo <[hidden email]> wrote:

I did not expected such a warm welcome and being in vain for more than a year..
Thank you all guys, you are great!

Yes, as i said i feel like i want to get some involvement.. So expect more acid in future, because that is my energy taking such unordinary form sometimes :)

I'm really happy for you.
If you can help with the SDL 20 integration. I'm not sure that everything you did in last year may was integrated. In fact we did not have the time
because of Spur and uFFI. In Pharo 60 we need to remove all the old event chain and only use OSWindows.

Ronie will arrive a5 of April to Lille and he wants to work on Woden but also it would be good to have his FFI (with special bytecode) integrated into the JIT
so I imagine that clement, eliot, esteban and ronie should talk.

I see. Thanks for heads up.

Stef

Best regards,
Igor Stasenko.

Ben Coman

Re: Catching Exceptions without any notice

In reply to this post by Tudor Girba-2

All forms of learning involve some degree criticism, and sometimes we
learn the most from the hardest task masters.

We all want a positive community, but we need to not fall into the
trap of... "hacker forums where, out of some misguided sense of
hyper-courtesy, participants are banned from posting any fault-finding
with another's posts, and told “Don't say anything if you're unwilling
to help the user.” The resulting departure of clueful participants to
elsewhere causes them to descend into meaningless babble and become
useless as technical forums. Exaggeratedly “friendly” (in that
fashion) or useful: Pick one. "
[http://www.catb.org/esr/faqs/smart-questions.html]

Its a balance to weave, but lets not be too quick on the trigger to
impede someone's natural flow of thoughts. If too much burden is
imposed to craft "cheerful" criticism, we might lose its contribution
and the chance to learn.

I learnt something from Igor's post.

cheers -ben

On Sat, Apr 2, 2016 at 6:07 AM, Tudor Girba <[hidden email]> wrote:

> Hi Igor,
>
> You are more than welcome to come back.
>
> Too much acidity is good neither for you nor for the people around you :). Let’s be kind with one another and assume that we all care and we want to make this world a better place, but that at the same time we are still only humans.
>
> Cheers,
> Doru
>
>
>
>> On Apr 1, 2016, at 10:51 PM, Igor Stasenko <[hidden email]> wrote:
>>
>>
>>
>> On 1 April 2016 at 09:53, Tudor Girba <[hidden email]> wrote:
>> Hi,
>>
>> Nice to hear from you Igor. I am glad to see you around here.
>>
>> Hi, Doru. Yeah, i am considering whether i want to return to things i left, or not. So, expect more of my acid sarcasm in future. Maybe :)
>>
>> I do not see how your quote applies to the current case given that the original authors did not leave anywhere, but perhaps it was a joke, and I did not get it.
>>
>> We all will leave sooner or later. The only what matters is what we left behind :)
>>
>> Cheers,
>> Doru
>>
>>
>> > On Apr 1, 2016, at 5:54 AM, Igor Stasenko <[hidden email]> wrote:
>> >
>> > A perfect example of careless programming.
>> > "I'll do it my way, and if it causing any problems, i don't care and i will just ignore them. And it's not my problem anyways, i went to something else already, since this part is works and DONE"
>> > :)
>> >
>> > On 30 March 2016 at 14:33, Nicolai Hess <[hidden email]> wrote:
>> > Please don't do this:
>> >
>> > updateHeight
>> > "no need to care about height, when it's logic is not customized"
>> > self layout isHeightCustom ifFalse: [ ^ self ].
>> > [ self bounds: (self brickBounds withHeight: self customHeight) ]
>> > on: Exception
>> > do: [ "just skip and do nothing" ]
>> >
>> > This makes debugging GLM/Brick ui/layout code with "self haltOnce" impossible.
>> > see
>> > GLMBrickGeometryTrait>>#updateHeight
>> > GLMBrickGeometryTrait>>#updateWidth
>> >
>> > And if you log out the raised exception, you see some calls to
>> > not initialized fonts and a ZeroDevide and some more errors.
>> > The above catch, catches and hides wrong / to late initialized objects.
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Igor Stasenko.
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "No matter how many recipes we know, we still value a chef."
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "It's not how it is, it is how we see it."
>
>