[DRMAA-WG] misssing exceptions and thread safety
D.Gruber at Sun.COM
Tue Mar 2 08:28:36 CST 2010
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?
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.
> 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.
>> On 1 March 2010 15:27, Andre Merzky<andre at 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 at ogf.org
> drmaa-wg mailing list
> drmaa-wg at ogf.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the drmaa-wg