The PM and UM have general catch all error handlers as fall back if the underlying API throws new Exceptions we don't know about. It should just pop up a dialog informing the user the error has occurred and displaying the exception str.
As a general rule if you are generating new Exceptions and want anything other than this default behavior in the GUI please file a bug against the GUI so we can do something about it, detailing the new Exception and what should be done with it. Thanks, JR > 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 > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
