Right, and I also checked that in fact the errors ought to have been caught anyway.
Validating the tests, will submit (as I think you okayed) when they're proven still unchanged. On Fri, Apr 17, 2009 at 2:50 PM, Lex Spoon <[email protected]> wrote: > On Thu, Apr 16, 2009 at 7:02 PM, Freeland Abbott <[email protected]> > wrote: > > On Thu, Apr 16, 2009 at 5:27 PM, Lex Spoon <[email protected]> wrote: > >> >> I wouldn't expect TypeExposureComputer to need to report any > problems. > >> >> Did you run any any cases where it should? Barring an argument to > the > >> > > >> > Not directly, no, but it's needed for pass-through to e.g. > >> > STOB.shouldConsiderFieldsForSerialization by way of > >> > computeIndirectExposureCauses(). > >> > >> In that case it seems better to pass in an empty problem report, as is > >> done for similar methods that expect a logger. > > > > Are we assured that the TIEC won't, in its wanderings back through STOB, > > visit anything that hasn't already been touched? (Bearing in mind that > > "visitation" now implies "creating TIC" which implies "short circuiting > > revisitation," so we only get one shot to collect problems uncovered....) > > If we are, then yes, instead of passing through I can create and discard > new > > ProblemReports. > > > It only calls static methods of STOB, and doesn't (or at least > shouldn't) even have an instance of STOB. Thus, it can't affect the > set of TICs directly. > > The overall pattern is that STOB creates a TEC to do some analysis for > it. It then queries that TEC for the results of those analysis > whenever it needs. Maybe those analysis results should be logged, but > nobody has worked out exactly how to do that. That's why it > previously passed TreeLogger.NULL; the analogous thing with your patch > would be a new ProblemReport whose data is ignored. > > Lex > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
