Re: Error semantics

Norm,

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.

I'd say:

  - you must not see the warnings generated by warning-a
  - 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.

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).

Don't know if you can express that in spec-speak...

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Monday, 19 May 2008 16:46:32 UTC