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