Hi Folx, I stumbled over the exceptions in the spec again. Tried to find what we decided on in respect to exception classes, but could not find a definite statement in the mailing list archive nor in the issue list or meeting note. So I discussed with hartmut again - well, turned out his memory is a bad as mine ;-) What we did remember (or though to) is: - if an exception is fatal or not depends on the use case ("Can't suspend job" - fatal or not?) - a non-fatal backend exception could be recovered from by the saga implementation, and would hence not reach the application - so we don't need it. If we can't recover, it might well be fatal. - obviously bad things like 'not enough memory' don't need to be put into saga exceptions - have nothing to do with saga semantics. 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. If that can be recovered from or not is up to the application. If there are no comments to the contrary within a week, and if nobody has better search or meeting notes, I'll update the spec accordingly. Cheers, Andre. -- "So much time, so little to do..." -- Garfield
Hello all, Just to support Andre and Hartmut!
- if an exception is fatal or not depends on the use case ("Can't suspend job" - fatal or not?)
Exact. The API can in most cases not decide what it is. I have cases where I consider a same exception as an internal signal and in order cases I throw it upwards to the application. Unless you can clearly identify "fatal" and eventually handle it, you should expose the problem to the application.
- a non-fatal backend exception could be recovered from by the saga implementation, and would hence not reach the application - so we don't need it. If we can't recover, it might well be fatal.
Yes, if the API can do nothing or don't know how to handle it, throw it upward. Their might be cases where the SAGA implementation differs. For example, if one implementation has disconnection recovery implemented and another not, one might mute and recover from the exception when the other will throw it.
- obviously bad things like 'not enough memory' don't need to be put into saga exceptions - have nothing to do with saga semantics.
Right, not in the API scope. In Java they are not even Exceptions but Errors (Fatal) and they are unchecked. You can trap them and eventually handle them, but in most cases it is hard to recover from them.
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. Anyway you have my support on this. -- Best regards, Pascal Kleijer ---------------------------------------------------------------- HPC Marketing Promotion Division, NEC Corporation 1-10, Nisshin-cho, Fuchu, Tokyo, 183-8501, Japan. Tel: +81-(0)42/333.6389 Fax: +81-(0)42/333.6382
Hi Pascal, thanks for the feedback! :-) Cheers, Andre. Quoting [Pascal Kleijer] (Feb 20 2006):
Date: Mon, 20 Feb 2006 09:09:01 +0900 From: Pascal Kleijer
To: Andre Merzky CC: SAGA RG Subject: Re: [saga-rg] exceptions... Hello all,
Just to support Andre and Hartmut!
- if an exception is fatal or not depends on the use case ("Can't suspend job" - fatal or not?)
Exact. The API can in most cases not decide what it is. I have cases where I consider a same exception as an internal signal and in order cases I throw it upwards to the application. Unless you can clearly identify "fatal" and eventually handle it, you should expose the problem to the application.
- a non-fatal backend exception could be recovered from by the saga implementation, and would hence not reach the application - so we don't need it. If we can't recover, it might well be fatal.
Yes, if the API can do nothing or don't know how to handle it, throw it upward. Their might be cases where the SAGA implementation differs. For example, if one implementation has disconnection recovery implemented and another not, one might mute and recover from the exception when the other will throw it.
- obviously bad things like 'not enough memory' don't need to be put into saga exceptions - have nothing to do with saga semantics.
Right, not in the API scope. In Java they are not even Exceptions but Errors (Fatal) and they are unchecked. You can trap them and eventually handle them, but in most cases it is hard to recover from them.
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.
Anyway you have my support on this. -- "So much time, so little to do..." -- Garfield
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
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
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
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
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
You are right, I forgot that one! :-) Andre. Quoting [Graeme Pound] (Feb 20 2006):
Date: Mon, 20 Feb 2006 13:17:15 +0000 From: Graeme Pound
To: Andre Merzky CC: Pascal Kleijer , SAGA RG Subject: Re: [saga-rg] exceptions... 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
-- "So much time, so little to do..." -- Garfield
participants (3)
-
Andre Merzky
-
Graeme Pound
-
Pascal Kleijer