[Pharo-dev] Catching Exceptions without any notice

Igor Stasenko siguctua at gmail.com
Fri Apr 1 19:20:37 EDT 2016

On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nergaard at uia.no> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160402/c3fc9a21/attachment.html>

More information about the Pharo-dev mailing list