[saga-rg] exceptions...

[Graeme Pound]

Andre,

Another common exception type would be 'NotImplemented'; if it is agreed 
that this is the best mechanism to describe the methods that an 
implementation was unable to provide.

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
> 
> 
>