19803, "dlongnecke-cray", "Should IllegalArgumentError be renamed? How about its initializer formal names?", "2022-05-12T19:24:16Z"
https://github.com/chapel-lang/chapel/issues/19803
Chapel currently offers the IllegalArgumentError as a subclass of Error. It lives in the automatic Errors module: https://chapel-lang.org/docs/modules/standard/Errors.html#Errors.IllegalArgumentError
It is intended to be thrown when the author of a method determines that a formal argument contains an incorrect value. A good example might be passing 0 to a division function:
operator /(lhs: myInt, rhs: myInt): myInt throws {
if rhs.value() == 0 then throw new IllegalArgumentError('rhs', 'cannot divide by zero');
return new myInt(lhs.value() / rhs.value());
}
Should we rename the class?
The name IllegalArgumentError feels a bit overly verbose to me, and I wonder if we might consider shortening the name to just ArgumentError.
In Python, such cases usually throw ValueError, but that is probably not a suitable replacement name on its own because Python also has a TypeError that it can throw when types do not match (recall that Python has dynamic typing). We do not need a TypeError in most cases since static type checking fills the same role.
Should we rename initializer formal names?
There are three initializers for the class.
proc init();
proc init(info: string);
proc init(formal: string, info: string);
The first initializer takes the formal info and uses it to initialize the superclass Error. The string info constitutes the entire message. Perhaps we could rename it to msg to be consistent with the Error class initializer?
The second initializer takes two strings and uses it to construct an error message. The first formal is the name of the offending formal (in the above division example, we might pass in rhs). The second formal info is meant to capture the reason why the formal was faulty.
Perhaps we could rename the second formal to reason instead of info?
I think the first formal name formal is probably good, though perhaps we could rename it to formalName.
Should we drop the zero argument initializer?
It feels a bit odd to have an initializer without a message. This initializer just invokes the superclass Error with no message at all (the field is completely empty). Though maybe this is acceptable when prototyping?