On 01/ 8/10 05:25 PM, John Rice wrote:
Shawn Walker wrote:
On 01/ 8/10 09:59 AM, John Rice wrote:
Hi - this adds a Transport exception handler when getting pkg list data
from the api.
I also uses logging in a number of Transport exception handlers in the
GUI where we formerly reported them to the user. This was resulting in
over reporting of transient transport errors in a number of places, in
particular when performing some long running searches.
http://cr.opensolaris.org/~jmr/pm_13736_transport_exception_8Jan_350pm/
Okay, so something that's concerned me for a while here is that the
error handling generally used in PM isn't quite right.
The pattern for exception handling should be something like:
try:
api_call()
except SpecificException1, ex:
# Handle specific exception case 1 that requires special handling.
except SpecificException2, ex:
# Handle specific exception case 2 that requires special handling.
except Exception, ex:
# Handle all remaining exceptions generically.
In this particular case, I would change line 4630 of
src/packagemanager.py to handle Exception, not TransportError.
Alternatively, if you want to handle ApiExceptions separately from
generic exceptions, then catch ApiException and Exception both.
Interesting - we are using the same pattern as the CLI in the pkg list
command and when we did put in generic handlers as you suggest, folks
complained about it on the list, saying we should explicitly handle the
errors and not put in a catch all.
The difference is that the cli has a top-level error handler that will
prevent traceback in many cases.
The other difference is that the GUI, unlike the CLI, will become
completely unresponsive if you don't handle the errors.
Otherwise, when the next failure case arises, this code is just going
to break again.
There only guarantee about what exceptions API calls can raise are
that they should always be an instance of ApiException.
I think this does raise a general issue.
Now that the API is stabilizing the Exceptions each API raise should be
documented as part of each API's interface so clients can reliably know
what they are meant to be handling. Then as long as we know we are
handling all the defined Exceptions correctly its fine to put in the
generic handler at the end.
To my mind Exceptions should always be part of the contracted interface
of an API, or is it just my Java heritage kicking in :)
It's really not practical to attempt to document all of the possible
ApiExceptions that every function can raise. Not only does that change
over time, but different error conditions can cause different exceptions
to be raised.
API consumers should expect ApiExceptions to be raised. If they want to
have special handling for specific ApiExceptions, that's fine too.
The stable interface for client error handling is to catch ApiException.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
