New Issue: Errors Module: the 'TaskErrors' class

Notifications Issues
1

21068, "jeremiah-corrado", "Errors Module: the 'TaskErrors' class", "2022-11-21T17:31:44Z"

https://github.com/chapel-lang/chapel/issues/21068

Background:

An instance of TaskErrors holds a collection of errors thrown during the execution of a parallel construct.

It allows patterns like the following:

try {
    coforall t in tasks do
        thingThatMightThrow(t);
} catch te: TaskErrors {
    for e in te do
        writeln(e);
} catch e { }

It also has first(), filter(type) and contains(type) methods to select out individual errors.

Suggestions/Questions:

  • In the above example, the error needs to be caught as a TaskErrors. If it is caught as a gereralError, then the iterator is not available.
    • I think we should we support a degenerate iterator on all error types (and override it for TaskErrors), s.t. the above example could be rewritten as:
    try {
    coforall t in tasks do
        thingThatMightThrow(t);
} catch te {
    for e in te do
        writeln(e);
}
  • Is the current interface ok? Should any methods be removed? (This question was discussed during the module review, and it sounds like people were leaning against changing the interface).
  • Not necessarily 2.0 (but might affect the choice of interface): should TaskErrors store its list of errors in an array rather than a linked list?