> > http://cr.opensolaris.org/~johansen/webrev-4381/ > > > I'm fine with this for now. I think in general, it's better to pass the > data to the exception directly, and have the str method build the > string. I couldn't find where FileListRetrievalError was defined though, > so I'm not certain if that's possible in this situation.
FileListRetrievalError is defined in filelist. I was keeping with the conventions that have been used for ManifestRetrievalError and DatastreamRetrievalError. The code for those exception handlers are all essentially the same. This exception does have a str method that prints the data; however, since we don't always know what's going to cause a retrieval error, I create some helpful message as the data, and then let the handler actually print out that string. > Can you test what happens to the Packagemanager when/if this new > exception reaches client code? Actually, from what I can tell, it > won't be any worse than what happened with the RuntimeException, but > we should still check, and file a bug against the gui if the exception > would take it down. I thought we had discussed this during the I/O Errors review, but I'm having a hard time finding any record of that. To my knowledge, the GUI wasn't catching any of the transport [FileList|Manifest|Catalog|Datastream]RetrievalError exceptions, so I'm not regressing existing behavior. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
