[drmaa-wg] Another Argument for a DRMAA_ERRNO_UNSUPPORTED_ATTRIBUTE Error Code

[Roger Brobst]

I think you have correctly identified that the error codes
specified in the C-lang spec for drmaa_set_attribute() do
not adequately describe the situation when an attribute is
not supported.

Should it ?
I did not locate any text in the spec which indicates that
it is an error to specify an unsupported (or unrecognized)
attribute.
On the other hand, I also did not locate any text which
indicates that unsupported attributes will be ignored.

I do distinctly recall discussion at GGF-6 (2002) related
to an ISV providing several DRMS-specific attributes for
several known implementations (where at most one 
implementation is deployed for the session).  
Bill Nitzberg made the observation, and Andreas effectively
made the case that Job Categories are a more appropriate
mechanism.


I don't think I fully understand the situation described
below:
> (Caching the supported argument list doesn't help if
> the list can change during the lifetime of the DRMAA
> application, as is the case with SGE.)

It would seem that if the set of supported attributes are
changing during a session, then validation should be
performed by the 'Job Valuator' when drmaa_run_job is
invoked; not at the time each attribute value is set.

-Roger


In a previous e-mail, Daniel Templeton wrote:
> That is a solution, but I have a fundamental problem with
> making developers jump through hoops to interpret the
> information returned from a call.  An error code should
> clearly indicate what the error is.  Overloaded error codes
> are bad.  They lead to very bad error handling practices.
> 
> Think about the man page.  Do you want to explain to
> developers that DRMAA_ERRNO_INVALID_ARGUMENT means either
> that an argument was bad, *or* that the attribute is
> unsupported, and that they'll have to retrieve and parse
> through a list of all the supported attributes to tell the
> difference?  Only 10-20 strcmp's later you'll know what
> the error meant!  What a bargain!
> 
> (Caching the supported argument list doesn't help if the
> list can change during the lifetime of the DRMAA
> application, as is the case with SGE.)
> 
> Daniel
> 
> Roger Brobst wrote:
> 
> >Given that the C-lang interface specifies the function
> >drmaa_get_attribute_names, it would seem that a Java
> >binding which leverages a C-lang implementation could
> >determine the supported attribute names.
> >
> >-Roger
> >
> >
> >In a previous e-mail, Daniel Templeton wrote:
> >  
> >
> >>I just uncovered a bug in the DRMAA Java language binding,
> >>that stems directly from the DRMAA_ERRNO_INVALID_ARGUMENT
> >>error code being used to indicate that an optional
> >>attribute is unsupported.  
> >>
> >>Rather obviously, the bug is that the property setters throw
> >>InvalidArgumentException instead of UnsupportedAttributeException
> >>for unsupported attributes, because the Java language binding 
> >>can't tell from the C binding whether the attribute is actually
> >>unsupported, or if the attribute is supported, but the argument
> >>to the setter is invalid.
> >>
> >>Daniel
> >>
> >>