Hmm, this is imho not the best solutions. Preventing NPEs by null checking smells a little bit :) If the section has been added recently than that author should now if a null for the object is a valid case or not; otherwise we should better remove the section for the release.
Carsten > -----Original Message----- > From: Unico Hommes [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 16, 2004 4:00 PM > To: [EMAIL PROTECTED] > Subject: Re: NPE in AbstractCachingProcessingPipeline > > The section that causes the NPE was added recently. If you > say that there are situations where it causes an NPE then I > believe you immediately. The code is rather incomprehensible > to me as well to say the least. Lots of side effects and null > states that are supposed to signal some sort of situation > that are probably not even clear to the original author > anymore. I guess I'll add a null check for this situation, > when SVN is up again that is. > > -- > Unico > > Jon Evans wrote: > > > Hi, > > > > Bugzilla appears to be broken... > > > > > > I've been chasing down a problem where the portal I'm > developing would > > work fine for a few iterations, then it would break and bits of it > > would be replaced with "The coplet xxx is currently > unavailable". The > > NPE logged in error.log was pretty hard to track down, in the end I > > had to step through the code. > > > > I tracked it down to the function > getValidityForEventPipeline(), the > > first section of which reads: > > > >> if (this.cachedResponse != null) { > >> final AggregatedValidity validity = new > >> AggregatedValidity(); > >> > >> for (int i=0; i < this.toCacheSourceValidities.length; > >> i++) { > >> validity.add(this.toCacheSourceValidities[i]); > >> } > >> return validity; > > > > > > The problem seems to be that this.toCacheSourceValidities is null. > > This would point to the fact that setupValidities() has never been > > called - or it's internal state is such that > setupValidities() ends up > > setting toCacheSourceValidities to null. I don't know > anything about > > the lifecycle of an AbstractCachingProcessingPipeline so I wouldn't > > know where to track that down. > > > > If a !=null test is added to getValidityForEventPipeline(): > > > >> if (this.cachedResponse != null) { > >> final AggregatedValidity validity = new > >> AggregatedValidity(); > >> > >> if (this.toCacheSourceValidities != null) { > >> for (int i=0; i < > >> this.toCacheSourceValidities.length; i++) { > >> validity.add(this.toCacheSourceValidities[i]); > >> } > >> } > >> return validity; > > > > > > then it seems to work (at least, my portal doesn't seem to keep > > falling over any more). > > > > If my patch isn't correct then I'd be happy to track this down > > further, if someone could point me in the right direction with some > > more information about how an > AbstractCachingProcessingPipeline gets > > constructed, and at what point in its lifecycle setupValidities() > > should be called. > > > > I'd appreciate some feedback / help on this one! > > > > Thanks, > > > > Jon > > > >
