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