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 cearly 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
-- *************************************************** * Daniel Templeton ERGB01 x60220 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * "Roads? Where we're going we don't need roads." * * -Dr. Emmett Brown * * Back to the Future (1985) * ***************************************************