[saga-rg] exceptions...

[Andre Merzky]

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