Re: [Pharo-dev] Catching Exceptions without any notice

[Ben Coman]

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  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  wrote:
>>
>>
>>
>> On 1 April 2016 at 09:53, Tudor Girba  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  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  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."
>
>

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 2 April 2016 at 17:31, stepharo  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[stepharo]

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

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 2 April 2016 at 14:13, Robert Withers  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Robert Withers]

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
.  ..   ...^,^

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 2 April 2016 at 12:44, stepharo  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 2 April 2016 at 12:45, stepharo  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[p...@highoctane.be]

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

Re: [Pharo-dev] Catching Exceptions without any notice

[stepharo]

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

Re: [Pharo-dev] Catching Exceptions without any notice

[stepharo]

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 > 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 mailto:nicolaih...@gmail.com>> 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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 2 April 2016 at 03:06, Robert Withers  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  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  wrote:
>
>>
>>
>> On 2 April 2016 at 01:13, Henrik Nergaard  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Robert Withers]

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  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  wrote:
>> 
>> 
>>> On 2 April 2016 at 01:13, Henrik Nergaard  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[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  wrote:

>
>
> On 2 April 2016 at 01:13, Henrik Nergaard  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 2 April 2016 at 01:07, Tudor Girba  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  wrote:
> >
> >
> >
> > On 1 April 2016 at 09:53, Tudor Girba  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  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  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 2 April 2016 at 01:13, Henrik Nergaard  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Henrik Nergaard]

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



Best regards,

Henrik

Re: [Pharo-dev] Catching Exceptions without any notice

[Tudor Girba]

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  wrote:
> 
> 
> 
> On 1 April 2016 at 09:53, Tudor Girba  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  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  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."

Re: [Pharo-dev] Catching Exceptions without any notice

[Eliot Miranda]

Hi Aliaksei, Hi Stef,

On Fri, Apr 1, 2016 at 2:40 PM, Aliaksei Syrel  wrote:

> Thanks for feedback :)
>
> Indeed, this is a nice case to learn from. That piece of code was written
> when I just started working with pharo after coming from Java world.
>
> 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 ].
>
> After setting an object as a new height, it gets evaluated and in case of
> example before throws DNU because owner is obviously still nil.
>
> Trying to improve overall readability I decided to ignore all errors in
> that kind of blocks instead of putting ifNil:ifNotNil: in hundred places.
>
> Also, I could not imagine that Warning is actually an Exception and
> exception (in its common sense) is an Error. However, I had in mind that
> later that kind of code smell should be replaced at least by custom error
> handler, like we have now in spotter that catches all errors allowing not
> buggy processors to do their work.
> Btw, in first versions of spotter it was the same: it catched exception
> instead of error but more experienced colleges suggested to not do it like
> that.
>
> Nevertheless, later I realized that blocks are evil, and instead of trying
> to work with nils it's much easier and cleaner to just put an assertion.
>
> As a hotfix, I will replace Exception to Error tomorrow. (bad, but
> still...)
>
> Don't hesitate to post code smells, at least we can make jokes of them :)
>

:-).  Stef, no one is "bashing someone".  We /must/ be able to criticise
code if we want the code base to get better, and this code was bad.
Aliaksei responded to the criticism positively and did not take it
personally.

But the interesting point is that Aliaksei and people like him are clearly
skilled programmers but they are coming to Pharo (or Squeak, or Smalltalk
in general) from other systems, and if we as a community are successful in
promoting Pharo, Squeak, Newspeak et al, we can expect many more people
like Aliaksei to come to our community and want to contribute.  So I wonder
if we have the energy and resource to write brief documentation on good
style vs bad style aimed at the experienced OO programmer who is trying
Smalltalk for the first time.  I think this is an important demographic to
serve, and I think the form of the documentation would be considerably
different to normal introductory texts; it can use a much steeper learning
curve and can go from "here's how you do it", to "here's how to do it
right" and "here's how not to do it", very quickly; something that the
usual introductory texts stay away from, leaving these important topics to
"advanced" course materials.

Cheers
> Alex
>
Cheers!


> On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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, Eliot

Re: [Pharo-dev] Catching Exceptions without any notice

[Aliaksei Syrel]

Thanks for feedback :)

Indeed, this is a nice case to learn from. That piece of code was written
when I just started working with pharo after coming from Java world.

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 ].

After setting an object as a new height, it gets evaluated and in case of
example before throws DNU because owner is obviously still nil.

Trying to improve overall readability I decided to ignore all errors in
that kind of blocks instead of putting ifNil:ifNotNil: in hundred places.

Also, I could not imagine that Warning is actually an Exception and
exception (in its common sense) is an Error. However, I had in mind that
later that kind of code smell should be replaced at least by custom error
handler, like we have now in spotter that catches all errors allowing not
buggy processors to do their work.
Btw, in first versions of spotter it was the same: it catched exception
instead of error but more experienced colleges suggested to not do it like
that.

Nevertheless, later I realized that blocks are evil, and instead of trying
to work with nils it's much easier and cleaner to just put an assertion.

As a hotfix, I will replace Exception to Error tomorrow. (bad, but still...)

Don't hesitate to post code smells, at least we can make jokes of them :)

Cheers
Alex
On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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.
>

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 1 April 2016 at 09:53, Tudor Girba  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  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  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

On 1 April 2016 at 21:52, stepharo  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  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[stepharo]

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.

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

Re: [Pharo-dev] Catching Exceptions without any notice

[Tudor Girba]

Hi,

Nice to hear from you Igor. I am glad to see you around here.

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.

Cheers,
Doru


> On Apr 1, 2016, at 5:54 AM, Igor Stasenko  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  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."

Re: [Pharo-dev] Catching Exceptions without any notice

[Igor Stasenko]

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

Re: [Pharo-dev] Catching Exceptions without any notice

[Gabriel Cotelli]

Handling Error will be an improvement. But we don't know the rationale for
handling Exception in the first place, if it's for ignoring some Warnings
and Errors then changing the handler to Error would break things. I was
trying to propose the less risky change, but I'm with you. The right
solution is not to make the handler too broad, even handling Error is a bad
smell.

On Thu, Mar 31, 2016 at 11:22 AM, Eliot Miranda 
wrote:

>
>
> On Mar 31, 2016, at 3:51 AM, Gabriel Cotelli  wrote:
>
> On the meantime at least change the handler to ignore the halts.
>
> ...  on: Exception - Halt
>
> Should do the trick
>
> Can someone say why
> ...  on: Error
> will not improve things?
>
> Exception - Halt is just /wrong/, less wrong than Exception but still very
> wrong.
>
> _,,,^..^,,,_ (phone)
>
> On Mar 31, 2016 06:57, "Esteban Lorenzano"  wrote:
>
>>
>> On 30 Mar 2016, at 19:54, Aliaksei Syrel  wrote:
>>
>> Do anyone really use GLM-Morphic-Brick?
>>
>> Because it is there just for spotter and will be deleted ASAP.
>>
>> We know that it is bad. Normal fix requires too many changes...
>>
>> but catching Exception is bad because it will catch all, even Warnings
>> and Halts.
>> It would be less bad if it catches Error (not Exception). Still bad, but
>> less bad :)
>>
>> Esteban
>>
>> On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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.
>>>
>>
>>

Re: [Pharo-dev] Catching Exceptions without any notice

[Eliot Miranda]

> On Mar 31, 2016, at 3:51 AM, Gabriel Cotelli  wrote:
> 
> On the meantime at least change the handler to ignore the halts. 
> 
> ...  on: Exception - Halt
> 
> Should do the trick
> 
Can someone say why
...  on: Error
will not improve things?

Exception - Halt is just /wrong/, less wrong than Exception but still very 
wrong.

_,,,^..^,,,_ (phone)

>> On Mar 31, 2016 06:57, "Esteban Lorenzano"  wrote:
>> 
>>> On 30 Mar 2016, at 19:54, Aliaksei Syrel  wrote:
>>> 
>>> Do anyone really use GLM-Morphic-Brick?
>>> 
>>> Because it is there just for spotter and will be deleted ASAP.
>>> 
>>> We know that it is bad. Normal fix requires too many changes...
>>> 
>> but catching Exception is bad because it will catch all, even Warnings and 
>> Halts. 
>> It would be less bad if it catches Error (not Exception). Still bad, but 
>> less bad :)
>> 
>> Esteban
>> 
 On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Gabriel Cotelli]

On the meantime at least change the handler to ignore the halts.

...  on: Exception - Halt

Should do the trick
On Mar 31, 2016 06:57, "Esteban Lorenzano"  wrote:

>
> On 30 Mar 2016, at 19:54, Aliaksei Syrel  wrote:
>
> Do anyone really use GLM-Morphic-Brick?
>
> Because it is there just for spotter and will be deleted ASAP.
>
> We know that it is bad. Normal fix requires too many changes...
>
> but catching Exception is bad because it will catch all, even Warnings and
> Halts.
> It would be less bad if it catches Error (not Exception). Still bad, but
> less bad :)
>
> Esteban
>
> On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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.
>>
>
>

Re: [Pharo-dev] Catching Exceptions without any notice

[Esteban Lorenzano]

> On 30 Mar 2016, at 19:54, Aliaksei Syrel  wrote:
> 
> Do anyone really use GLM-Morphic-Brick?
> 
> Because it is there just for spotter and will be deleted ASAP.
> 
> We know that it is bad. Normal fix requires too many changes...
> 
but catching Exception is bad because it will catch all, even Warnings and 
Halts. 
It would be less bad if it catches Error (not Exception). Still bad, but less 
bad :)

Esteban

> On Mar 30, 2016 1:34 PM, "Nicolai Hess"  > 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.

Re: [Pharo-dev] Catching Exceptions without any notice

[Nicolai Hess]

2016-03-31 10:51 GMT+02:00 Tudor Girba :

> Hi Nicolai,
>
> Thank you for the feedback. Just, please let’s adopt a different tone.
>
> Cheers,
> Doru
>
>
>

I am not sure what is wrong with my tone.
I did not choose a random external library and starting to criticize it.
This is a core component. And

"Because it is there just for spotter and will be deleted ASAP.

We know that it is bad. Normal fix requires too many changes."
is not an excuse for badly debuggable code.
I don't like to have quick-dirty-throwaway-hacks in the core.
There is a real demand for debugging this code.
The attached screenshot shows a common issue with inspector panes.
The available space would suffice for all tabs (secodn window) but the
default
size shnrinks nearly all tabs (first window).

The normal way to understand and trying to fix this issue, is to put some
"self halt" at some point for the layout processing.But this does not work
here
because *all* exceptions are catched.
And changing the code to actually execute the exception won't work either,
becuase this
will throw all other (previously cachted) exceptions (what is wrong with
initializing the font property properly or
checking for ZeroDivide?)
And this is frustrating.
And I hope no one sees and adopts this code, just because it is the way our
own
core tools are built.

BTW, your LazyTabGroupMorph class is another bad example. It subclasses
TabGroupMorph, it
calls super initialize,
removes all created and added morphs from its super class and
recreates and replaces them with its own.

nicolai

Re: [Pharo-dev] Catching Exceptions without any notice

[Tudor Girba]

Hi Nicolai,

Thank you for the feedback. Just, please let’s adopt a different tone.

Cheers,
Doru


> On Mar 31, 2016, at 8:37 AM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-03-30 19:54 GMT+02:00 Aliaksei Syrel :
> Do anyone really use GLM-Morphic-Brick?
> 
> We all "use" it, our tools are build with this. 
> (inspector/debugger/playground/spotter).
>  
> Because it is there just for spotter and will be deleted ASAP.
> 
> 
> Not only for spotter. And if our tools are build with this, people may try to 
> use this
> for their own tools. This is the core image, and the core tools. What should 
> we
> say? 
> Please don't use it, but our core tools are built on this?
> 
>  
> We know that it is bad. Normal fix requires too many changes...
> 
> 
> No excuse. 
> 
>  
> On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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.
> 

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

“Live like you mean it."

Re: [Pharo-dev] Catching Exceptions without any notice

[Nicolai Hess]

2016-03-30 19:54 GMT+02:00 Aliaksei Syrel :

> Do anyone really use GLM-Morphic-Brick?
>
We all "use" it, our tools are build with this.
(inspector/debugger/playground/spotter).


> Because it is there just for spotter and will be deleted ASAP.
>

Not only for spotter. And if our tools are build with this, people may try
to use this
for their own tools. This is the core image, and the core tools. What
should we
say?
Please don't use it, but our core tools are built on this?



> We know that it is bad. Normal fix requires too many changes...
>

No excuse.



> On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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.
>>
>

Re: [Pharo-dev] Catching Exceptions without any notice

[Aliaksei Syrel]

Do anyone really use GLM-Morphic-Brick?

Because it is there just for spotter and will be deleted ASAP.

We know that it is bad. Normal fix requires too many changes...
On Mar 30, 2016 1:34 PM, "Nicolai Hess"  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.
>

Re: [Pharo-dev] Catching Exceptions without any notice

[Richard Sargent]

Nicolas Cellier wrote
> Isn't catching too wide an anti-pattern?

Yes!
Just think of all the Exception subclasses which are *not* errors. This kind
of thing effectively disables them.



> 2016-03-30 13:33 GMT+02:00 Nicolai Hess <

> nicolaihess@

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





--
View this message in context: 
http://forum.world.st/Catching-Exceptions-without-any-notice-tp4887402p4887460.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Catching Exceptions without any notice

[Nicolas Cellier]

Isn't catching too wide an anti-pattern?

2016-03-30 13:33 GMT+02:00 Nicolai Hess :

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

[Pharo-dev] Catching Exceptions without any notice

[Nicolai Hess]

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.