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 <siguc...@gmail.com> wrote: > > > On 2 April 2016 at 01:13, Henrik Nergaard <henrik.nerga...@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. > -- Best regards, Igor Stasenko.
