Re: Open issue: error codes

I feel that the point has already been made that the error codes are for users of the language as well as implementers: having named errors allow users to see where they may have gone 'wrong'.


Presentation notwithstanding, links should go in both directions.

Perhaps option 3 is the best compromise.

_________________
Tomos Hillman
eXpertML Ltd
+44 7793 242058
On 19 Apr 2022, 14:56 +0100, Steven Pemberton <steven.pemberton@cwi.nl>, wrote:
> 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:59:41 UTC