Date: 1 Feb 1999 18:20:31 -0000
Message-ID: <19990201182031.22340.qmail@zap.ml.org>
From: Ben Hyde <bhyde@pobox.com>
To: new-httpd@apache.org
Subject: APR Error Protocol - take 2.
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


Dean points out this never made it thru and I see it was
do to a typo on my end.  - ben

---

Back to the error handling discussion.

Having stood back from this for a while I think we ought to
agree that: The errno protocol is the way to go.

If, as we go along, we want to enhance this with other cool things -
that's fine.  But I don't think we can agree to those things now.  We
badly need code.  Code will hold the nose of these discussions to the
grind stone.

Lots of fun things might be piled on - some of these I'm a fan of - but
let's defer them.
 - using throw for connection killing errors.
 - standard support for logging classification schemes.
 - standard error instance description schemes.
 - etc. etc.

To be specific this is my proposal.  

- The APR errno Error Protocol -

APR routines notify their callers that an error has occurred by
returning an exceptional value that is easily distinguished from their
usual return value.  This exceptional value is often -1, or zero.
When ever a routine returns it's exceptional value it must set a
positive value in errno.  Errno is thread/fiber local storage.
Symbol names for all errno values are enumerated in apr_errno which
includes the usual unix errno.h.  APR client code may allocate
additional errno values in the region above 4000.  Errno is of
type int, i.e. it's size is compiler/platform specific.

It is entirely appropriate for routines to capture errors encountered
by their subroutines and handle them by: ignoring, logging, marking
some data structure, or invoking an alternative error protocol.  Such
alternatives error handling approaches may appear in the APR routines.

 - ben