The only thing is that we loose information on languages that do not support exception inheritance. For example when throwing CantApplyToCurrentStateException while resuming it is unclear weather it is because the job was terminated or it was not suspended. Maybe we should make the more general exceptions part of the language bindings? Daniel On 03/02/10 15:19, Daniel Templeton wrote:
Sounds reasonable to me. At a minimum, all of these very specific state exception should inherit from a more general exception in languages that support it.
Daniel
On 03/01/10 22:24, Mariusz Mamoński wrote:
Hi all,
1. Can we merge JobAlreadySuspendedException, JobNotSuspendedException, JobTerminatedException into one something like CantApplyToCurrentStateExecption (OGSA-BES approach) and state that the error message should bears current job state ? 2. Guaranteeing atomicity (concerning operation that comes from outside) in DRMAA is almost impossible for the DRMS i know, as usually there is no "lock on job" operation available in public API.
Cheers,
On 1 March 2010 15:27, Andre Merzky<andre@merzky.net> wrote:
Hi Dan,
Quoting [Daniel Templeton] (Mar 01 2010):
There is, however, no need to make the exception explicitly optional. Exceptions are by definition optional.
This may be true in this case, but in general I expect exceptions to be guaranteed on specific circumstances. For example, I would expect that a suspend() on an invalid jobid will *always* cause an exception (mandatory), not only sometimes (optional).
Best, Andre.
-- Nothing is ever easy. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg