24882, "lydia-duncan", "[Bug]: throwing hash functions generate an unavoidable error in error handling relaxed mode", "2024-04-17T22:08:06Z"
Summary of Problem
Description:
The user can define a hash function that throws, but only so long as the hash function is not defined inside a module. Once the code is in a module, "relaxed" mode error handling will cause the compiler-generated hash function that calls the user-defined one to generate an error. Since the function is compiler generated, the user cannot resolve this issue themselves
Is this a blocking issue with no known work-arounds?
There are workarounds, but they are not great imo:
- Make the hash function halt instead of throw
- Thwarts the ability to handle errors, which a user probably would want to do (since they marked the function as throwing to begin with)
- Don't wrap the code containing the hash function in a module
- Makes it less obvious how to access the code inside the module. Still possible, but forces the user to use a less polished structure for their project
- Make the module a
prototype
module- Means the entire module cannot get checked for stricter error-handling. Note that this also applies to the previous work-around
Steps to Reproduce
Source Code:
module throwingHashInModule { // module decl essential to exhibit the problem
record myRec: hashable {
var x: int;
proc hash(salt = 0): uint throws {
// This is not meant to be a good hash function, just to test throwing
if (salt == 0) then throw new IllegalArgumentError("salt too obvious!");
else return x*salt;
}
}
proc main() {
var myR = new myRec(15);
try {
var hash1 = myR.hash();
} catch e: IllegalArgumentError {
writeln(e.message());
var hash2 = try! myR.hash(3);
writeln(hash2);
} catch e {
halt(e.message());
}
}
}
Compile command:
chpl foo.chpl
Execution command:
N/A
Associated Future Test(s):
test/hash/throwingHashInModule.chpl
#TBD
Configuration Information
- Output of
chpl --version
: chpl version 2.1.0 pre-release - Output of
$CHPL_HOME/util/printchplenv --anonymize
: Should be any - Back-end compiler and version, e.g.
gcc --version
orclang --version
: N/A - (For Cray systems only) Output of
module list
: N/A