WORD!, PATH!, and URL!s as ERROR! ids

R3-Alpha gave all the built in errors categories and a WORD! for an id. These were established in the %errors.r file:

https://github.com/rebol/rebol/blob/master/src/boot/errors.r

Each category had an integer "base" number, and the errors were numbered according to that. Adding and removing errors would disrupt these numbers... so the idea was presumably that these would settle over time. At some point of stability, errors removed from the middle would not have their numbers reused, while new errors would be added at the end of their groups.

But the usage of integers for error codes isn't very "ecology friendly". I question the wisdom of even having error numbers in Rebol...IDs may collide, but numbers will do so even quicker. A lot of places you might imagine they'd be useful they aren't really; for instance, exit status codes for processes on UNIX are limited to bytes...and even in that limited range they use conventions other than Rebol's numbers.

To mitigate collisions, I've wondered if errors might be based on some kind of hierarchy, in which you could choose to refer to errors by WORD!, PATH!, or URL!.

error/id ~= 'missing-delimiter
error/id ~= 'syntax/missing-delimiter
error/id ~= http://rebol.info/e/syntax/missing-delimiter

So the idea being that the error IDs would be fully qualified somehow, but when you trapped them you could use a level of specificity that met your particular desires for rigor. If you were worried there was some other kind of 'missing-delimiter error that could be thrown affecting your particular code, you might use a full URL. I made up the ~= operator here as something you might use which would gloss this difference.

This isn't really a concrete proposal...just pointing out that I don't think numbering errors has a lot of point. While the names have changed here and there, the numbers have thus far had basically no meaning. It seems to me any future-forward strategy would avoid inventing error numbers entirely (an error of course might include a number as part of its parameterization if it's referring to a non-Rebol system, e.g. HTTP error codes).

So if we killed the numbering, would anyone notice?

I used to check error numbers as it's easier than checking for literal text.

I wonder if FIND/LAST/MATCH is the "operator" I'm suggesting here.

find/last/match error/id /missing-delimiter
find/last/match error/id /syntax/missing-delimiter
error/id = http://rebol.info/e/syntax/missing-delimiter

This modifies to suggest REFINEMENT!, REFINEMENT!-headed PATH!s, or URL! for ERROR! ids.

The reason I suggest REFINEMENT! vs. WORD! is so you don't wind up doing id: http://rebol.info/e/syntax/missing-bad-delimiter then find/last/match id 'bad-delimiter and get a false positive.

So would be nice if /syntax/missing-delimiter was a 2-element PATH! with a refinement at its head, and that such paths are inert like refinements are.