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