From: Mark S. <mar...@gm...> - 2008-12-02 23:51:41
|
Yes, the simple fix is as you state. However, the purpose for sub-classing is to use the super-class constructor routines to initialize stuff at that superclass level, and use the sub-class constructors to call the super class constructor, and then initialize what the sub-class needs. Without doing proper constructors, at all levels, you wind up forgetting to initialize something (as in this case). It may introduce some extra code in some places, but it reduces errors like this one. Am I not being clear? I hate messy code, and would much prefer to follow at least a pseudo-standard. I was using "required" and "needed" because when I tried to create just the super-class constructor, the compiler complained the sub-class did not have the appropriate constructor. So I created those, and cleaned up stuff as I saw it needed to be cleaned up. On Tue, Dec 2, 2008 at 3:13 PM, Erik Vos <eri...@hc...> wrote: > I have adjusted my copies of the various classes to resolve this Null > Pointer Exception, by creating constructors for the Round, StockRound, > OperatingRound and the sub-classes of StockRound. It does require > modifications of all of these for the constructors. A total of 8 classes to > update. (the sub-classes of OperatingRound does not require an update. But > probably should have constructors created for consistancy's sake. > > The simple fix would have been to add > > * this*.companyManager = gameManager.getCompanyManager(); > > to the ShareSellingRound constructor. That works for me to fix the problem > (which I have reproduced). Not sure what you are trying to achieve by adding > all these constructors. > > As for the second suggestion, I have indeed implemented the constructors > such that the super-classes do all the initialization that should, and the > sub-classes do the initialization they should. In a couple of places I > needed to create a constructor that simply called the super class > constructor and nothing more. > > I wonder why you are using worls like "required" and "needed": such default > constructors can be omitted. > > I have noticed that XCode does warn about several classes marked as > deprecated (in your comments) that are still being used. But the deprecation > comment does not specify what should be used instead. Those might be a > better item to clean up then simply adding JAVA Docs. > > Good point. Thanks. > > Erik. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |