Perhaps another point of view will help.  I'm the maintainer of
RFC 88: Omnibus Structured Exception/Error Handling Mechanism
(as at

My experience of the RFC process was good to very-good; some would
rate the process fair to good.  I don't think it deserves a poor or
an excellent.

The mechanism proposed by RFC 88 is *much* better than was the one
I started with, solely as a result of the input from those who
contributed to the topic.  I had a good head of steam up going in,
because this is a pet topic of mine, and because we have been using
a similar mechanism in-house with Perl 5.  But as is often the case,
showing the work to others interested in the topic produced numerous
good-to-excellent suggestions for both enhancements and for
simplifications.  In the case of RFC 88, this must be considered to
be the overwhelming result.

Overall, I think that the single change that would have had the
greatest effect on the quality of the whole RFC effort would have
been to run the RFC process over six months.  I spent over 200 hours
on RFC 88, I sent ~150 messages to the mailing list, and the RFC
ended up thirty printed pages long.  There was hardly time to think.
I couldn't have done it if hadn't been the dog days of August during
a slow spot in my job.  I can understand how those who attempted
more than one or two RFCs in the allotted time would have been unable
to be so complete in each such RFC.  And I understand that such a
long period would have produced other problems.

RFC 88 began life as a counter-proposal to Peter Scott's RFC 63
(Exception Handling Syntax) initially because I though we should
separate exception "objects" from exception handling.  I also
authored RFC 96 (A Base Class for Exception Objects), to compliment
88, but it ended up being similar to Peter's RFC 80 (Exception
Objects and Classes for Builtins) which he published at about the
same time.

It turns out that Peter and I had quite similar approaches, and
so over time he withdrew RFC 63 and became co-author of RFC 88.
I withdrew RFC 96, and we delegated the details for builtins to
RFC 80 (which is maintained by Peter).

So we ended up with two RFCs, 88 on exception handling and generic
exception objects, and 80 on how exception objects should be used
for exceptions in builtins.  I think the process was quite effective
here.  I think that having a separate (if misnamed) mailing list for
"errors" and exceptions was, in this case, effective.

Since RFC 88 was based on an existing Perl 5 implementation, it
was quite straightforward for us to build a complete simulation of
the proposed implementation (modulo syntactic details) based on
using C<die> and C<eval> as primitives, and to provide regression
tests thereto (as at
I understand that such an approach to IMPLEMENTATION DETAILS may not
be applicable to all other RFCs (but don't underestimate the value
to all of being able to point to the code and regression tests and
say, "um, yes, it does actually work" ;-)

With the prodding and help of Peter and the other contributors, RFC
88 ended up containing quite a detailed review of the issues raised
and discussed during the RFC process.  We probably would have better
results if all other maintainers had simply kept a folder of the
mail relevant to their RFC and summarized it before freezing.  Note
though that at one point concern was raised as to whether or not RFC
88 was simply getting too big, because of all this documentation.

There were of course the usual problems inherent in conducting
technical discussion via a mailing list (but I developed a thick
skin in comp.lang.c in c.1987 ;-)  Here are a few notes thereto that
may be of interest to archeologists or the designers of the next RFC
process (if any).

  * Not all readers are familiar with every topic.  Provide enough
    introductory explanation of what you are proposing, and why, to
    help those readers avoid unnecessary "requests for information".
    Don't put the technical details of a proposal before the
    explanation, because that will apparently prevent some readers
    from proceeding to the explanation before "requesting additional

  * A great deal of heat, and some light, was generated by concerns
    that imposition of RFC 88 in and of itself would change the very
    nature of what we know as love as Perl.  That wasn't the case,
    but quite some effort was devoted to the matter in spite of that.
    The lesson is: don't underestimate the importance of the IMPACT
    section, and if appropriate, state your disclaimers up front.

  * There was the usual confusion caused by those whose experience
    with exception handling was limited to its use for error
    handling, and by those who only had experience with exception
    handling in one or two other languages.  Here again considerable
    effort was devoted to alleviating those concerns in the RFC.

  * The usual tension between theoreticians and pragmatists, and
    between scripters, application developers, and framework
    developers, was apparent.  RFCs would do well to address these
    issues when they are promulgated.

Perhaps if there had been a longer period over which the RFCs could
have matured, we would have had more opportunity for "natural" topic
architects to emerge, after which they could have merged alternative
contributions into a whole, properly covering the issues discussed
above and elsewhere.  I would have liked to contribute more to the
OO topic than just RFC 92 (Extensible Meta-Object Protocol), but
fortunately Damian effectively held the architecture chair thereto,
so I could relax.  Similarly, with more time I imagine more complete
proposals for things like functional operations and continuations
could have matured.

Having said all this, I wouldn't complain about the whole thing too
much.  I can certainly point to any number of mailing lists where
the discussions would not have gone anywhere nearly as well! (And
don't forget that all this dynamic tension is part of the fun of
lightweight process methodologies ;-)

Thanks again to Peter Scott, Graham Barr, Chaim Frenkel, Jonathan
Scott Duff, Glenn Lindermann, Dave Rolsky, Corwin Brust, Jim Hoover,
and the Software Engineering Research Lab at the University of
Alberta, for your contributions to RFC 88.

Yours, &c, Tony Olekshy

Reply via email to