Be careful with the exceptions you catch
turam at mcs.anl.gov
Mon Feb 10 17:04:56 CST 2003
Chiming in late, after returning from vacation...
You are right that exception handling needs some work. Any exception
handling that I've inserted has been purely for debugging, since the
SOAP server silently swallowed exceptions. It was not intended to serve
a purpose beyond that, and I knew it would need another pass to resolve
all problems like the ones you pointed out.
Robert Olson wrote:
> This code:
> uri = self.profile.homeVenue
> self.client = Client.Handle(venueUri).get_proxy()
> except: # the address is incorrect
> # open a dialog and connect that way
> connectToVenueDialog = ConnectToVenueDialog(NULL, -1,
> 'Connect to server')
> if (connectToVenueDialog.ShowModal() == wxID_OK):
> uri = connectToVenueDialog.address.GetValue()
> is broken in a couple of ways.
> First, it will always require one to enter an address. The problem is
> that the exception that was caught was
> exceptions.UnboundLocalError local variable 'venueUri' referenced
> before assignment
> The unqualified except catches everything - syntax errors, missing
> names, etc.
> Second, EnterVenue is also wrapped in an unqualified try:except:
> block, and hence catches the GSITCPIOException that is what the
> calling code is looking for. If we are going to use exception handing
> in the upper levels to snag exceptions raised by the lower, and depend
> on lower level code raising exceptions for proper behavior, the
> exceptions need to be either not caught on the lower level or
> re-raised properly.
> The following change to the except clause in VenueClient.EnterVenue
> causes the proper behavior to be seen:
> except IOException, e:
> print "Exception in EnterVenue : ", sys.exc_type,
> raise e
> IOException is a new symbol imported from AccessGrid.hosting.pyGlobus;
> it is a renaming of pyGlobus.io.IOBaseException.
More information about the ag-dev