error handling: non-inlined iterators cannot throw

[mppf]

As a Chapel user, I would like to be able to write iterators that throw whether they are inlined or not because I expect to be able to combine language features to achieve my goals. Additionally I would like library supported iterators, such as FileSystem.listdir, to throw errors so that I can handle them appropriately in my programs and libraries.

See for example

test/errhandling/ferguson/it-throws-noinline.chpl

At the present time, only iterators that are inlined can throw. Otherwise the compiler generates an error because this code path is not implemented completely yet. This issue is a place to refer to this problem.

Perhaps the iterator lowering process should make 'throwing' those functions built from the iterator (advance, zip1, zip2, etc) that contain code that was setting the error argument in the original iterator.

Because of this issue, some standard library iterators that should be marked throws instead halt on error:

• ItemReader.these() (used in file.lines())
• channel.matches()
• RecordReader.stream_num() and RecordReader.stream()
• FileSystem listdir()

Tests that are skipif-ed for nightly testing with --baseline include:

test/library/packages/csv/CSVtest.chpl

These should be updated to throw once this issue is resolved.

[ronawho]

Considering that iterator inlining is an optimization that can be disabled with --baseline, or --no-optimize-loop-iterators --no-inline-iterators I don't think we should add error-handling to any iterator until this is implemented.

And note that some iterators can be direct inlined (--inline-iterators), but cannot be zippered inlined (--optimize-loop-iterators) since the limitations on the iterator for the 2 inlining methods are different.

[mppf]

@ronawho - right, we havn't been adding error handling to iterators in the modules for this reason. (edit - at least as far as I know).