Re: Error semantics

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| On 19 May 2008, at 09:48, Norman Walsh wrote:
|> Consider this pipeline of sequential steps:
|>
|> <p:pipeline ...>
|>  <p:warning-a ...>
|>
|>  <p:try>
|>    <p:group>
|>       <p:warning-b ...>
|>       <p:error ...>
|>    </p:group>
|>    <p:catch>
|>        ...
|>    </p:catch>
|>  </p:try>
|>
|>  <p:warning-c ...>
|> </p:pipeline>
|>
|> Where the "warning" steps write to their error port but don't fail.
|> The error step writes to its error port and fails.
|>
|> If I read the errors in the catch, ...
|>
|> - [May I | Must I | Must I Not] see the warnings generated by
|> warning-a?
|> - [May I | Must I | Must I Not] see the warnings generated by
|> warning-b?
|> - [May I | Must I | Must I Not] see the warnings generated by error?
|>
|> If I read the errors after warning-c, what can I/must I/must I not
|> see?
|
| The spec's a bit unclear -- "The error document may contain messages
| generated by steps that were part of the initial subpipeline." -- and
| implies that it's fine for the document to contain nothing at all.

Right.

| I'd say:
|
|  - you must not see the warnings generated by warning-a

Interesting. Mentally, I'd filed that in the "may" category. Not for
any particular reason, I guess, except that when my first
implementation strategy for errors turned out to be a total waste of
code, my redesign happened to include the warnings generated by
warning-a if I don't explicitly remove them.

|  - you may see the warnings generated by warning-b
|  - you must see the warnings generated by error
|
| The reason for 'must not' on warning-a is that it isn't in the scope
| of the <p:try>.
|
| The reason for 'may' on warning-b is simply that an implementation
| might implement warning-b in such a way that any warnings generated
| are invisibly dropped. And that's OK. But we explicitly say that
| p:error adds something to the error port, so it must show those
| warnings.

Ok, what I meant by warning-b was that it *did* write its warnings to
its error port, so in that case you would expect to see them, right?

| If you read the errors after warning-c (ie the call the pipeline is
| itself in a p:try) then I think you may see the warning-a and warning- 
| c warnings, but must not see the warnings within the <p:try> in the
| pipeline (because those warnings have been caught already).

Right.

There's definitely some scoping to be worked out.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Ignorance is a precious commodity: once
http://nwalsh.com/            | it's gone, you can't get it back.