[saga-rg] exceptions...

Graeme Pound G.E.POUND at soton.ac.uk
Mon Feb 20 06:41:43 CST 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
> 
> 
> 





More information about the saga-rg mailing list