Hi Graeme, I absolutely agree to your statements! The spec right now says: The exceptions below are sorted, most specific ones first, least specific ones last. On any error condition, the most specific exception possible MUST be thrown. I hope that helps the end users - and avoids overly frequent use of NoSuccess (which is the least specific exception in SAGA). Cheers, Andre Quoting [Graeme Pound] (Feb 20 2006):
Andre,
I will checkout the specification and have a look. It is about time that I iterated my Java bindings to bring them up-to-date with the latest version of the specification.
From the Java perspective I must define all of the possible exceptions that may be thrown by a method in the generic API interfaces. Although it may make sense for the specification to describe common exceptions, and list only additional exceptions for each method
Obviously this is a problem of finding the correct resolution at which these exceptions are defined. By creating specific exceptions we allow the client code to handle different conditions appropriately. There is little point in attempting to describe each possible error condition than may arise. Equally it does not serve the user of the API to squeeze all error conditions into 'NoSuccess'.
I guess that the guide should be to describe error conditions that may be expected to occur, and which it is useful to distinguish from a generic 'NoSuccess'. This classification need not be too fine-grained.
Graeme
Andre Merzky wrote:
Hi Graeme,
I updated the exception description in CVS today - I would be grateful if you could give it a sanity check.
As for specifying the exceptions for each call: you are right, we should try to define that as complete as possible.
However, I think that some of the exceptions might be implementation defined. For example: an implmentation might have attributes stored remotely, and might have authorization attached. So it should be able to throw AurorizationFailed on attributes. For other implementations that might not make sense.
Similar considerations would probably lead to have almost all exceptions on almost all method calls. At least:
IncorrectSession AuthentificationFailed AuthorizationFailed PermissionDenied BadParameter Timeout NoSuccess
are applicable to most operations I assume, depending on how they are implemented (assume an implementation which forwards _all_ SAGA calls to a web service, as could be done on top of gLite for example).
Would it make sense to list these exceptions on all calls? I think it is simplier to state that they can always be thrown, and list only the few additional exceptions on the calls.
What do you think?
Cheers, Andre.
Quoting [Graeme Pound] (Feb 20 2006):
Andre, Pascal,
So, I/we _think_ the agreement was to have only one simple saga::exception class which gets thrown whenever something happens which violates the semantic contract of a saga call. The different implementation can always sub-class them to provide better exception semantic. A single saga::exception class is more then enough.
This approach is fine. Within the Java I have been subclassing exceptions with reference to the 'types' of exception described in the details of the specification. Unfortunately this description is incomplete at present.
It is important that the description of different types of exception that may be thrown by each method is completed, and expanded where appropriate.
Graeme
-- "So much time, so little to do..." -- Garfield