Re: Open issue: error codes

I find that all the proposals make the spec less readable. These error codes are for implementers, not users of the language, and consequently make the spec less approachable.
So my proposal is that we do it the other way round: an appendix listing all errors, with links from there to the paragraph where they originate.

I also dislike the "s001" style of numbering, since it suggests that there are going to be hundreds of them. "s1" conveys the same information.

Steven

On Monday 18 April 2022 11:06:51 (+02:00), Norm Tovey-Walsh wrote:

> Hi,
>
> In the interest of starting substantive email discussion, I’m going to
> send out several messages about open issues. I’ll state my personal
> opinions about how I’d like to see them resolved. I encourage everyone
> in the CG to reply with their opinions. (I have been in working groups
> where progress was made by email!)
>
> My take on the error codes draft is that we might still get consensus on
> proposals three or four. I think we have recorded objections to
> proposals one and two.
>
> Proposal three is to use “(error Xxxx)” in the prose, with a link to an
> appendix of error codes.
>
> Proposal four is to accept proposal three but also to add the text of
> the error message(s) in new paragraphs below the where the error occurs.
>
> I’m happy with either three or four. In the interest of being concrete,
> I’ll express a slight preference for four. I think it’ll make the draft
> easier to understand on a first reading and I think the error paragraphs
> are distinct enough that they’re easy to skip over on subsequent readings.
>
> Be seeing you,
> norm
>
> --
> Norm Tovey-Walsh
> Saxonica
>
--

Received on Tuesday, 19 April 2022 13:56:07 UTC