Generators and propagation of exceptions

[r]

Terry, Ian, thank you for your answers.

On Sat, Apr 9, 2011 at 1:30 AM, Terry Reedy <tjreedy at udel.edu> wrote:
[...]
> According to the above, that should be stream-of-parsed-expressions.

Good catch.

> The question which you do not answer below is what, if anything, you want to
> do with error? If nothing, just pass. You are now, in effect, treating them
> the same as normal results (at least sending them down the same path), but
> that does not seem satisfactory to you. If you want them treated separately,
> then send them down a different path. Append the error report to a list or
> queue or send to a consumer generator (consumer.send).

The code above implements an interactive session (a REPL). Therefore,
what I'd like to get is an error information printed out at the output
as soon as it becomes available. Piping the errors together with data
works fine (it does what I need) but it feels a bit clunky [1]. After
all exceptions were specifically invented to simplify error handling
(delivering errors to the caller) and here they seem to chose a
"wrong" caller.

Ignoring the errors or collecting them out of band are both fine ideas
but they don't suit the interactive mode of operation.

[1] It's actually not _that_ bad. Exceptions still are very useful
inside of each of these procedures. Errors only have to be handled
manually in that main data path with generators.

Thanks,

-r