Re: LDAP C API: ber_* error handling

["Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>]

At 07:55 AM 6/19/99 -0500, Mark Wahl wrote:
>I would not be in favor of text that says:
>  this document does not describe how to retrieve BER errors.  However, 
>  implementations should provide a means.
>
>If a client uses Innosoft's method to retrieve this, would that client 
>work against OpenLDAP, Netscape or Novell?
>
>This is not suitable for a standards-track specification as it will not 
>lead to interoperability.  Either a mechanism needs to be defined, OR the
>issue not addressed, or clients told NOT to attempt to obtain BER errors
>until there is a standard.

I would say ldap_init (just for starters) needs a
little work as well....

	"These routines return NULL if the session cannot be
	initialized in which case the operating system error
	reporting mechanism can be checked to see why the called
	failed."

What's an operating system error reporting mechanism?  Besides
being operating system dependent, it's implementation dependent.

Error handling is a slippery slope.  If you want a standard
mechanism for obtaining detail error information, the specification
will need major rewriting.  If you want to maintain compatibility
with existing implementations, you'll need to leave the mechanism
"implementation specific."

This is quite similar to the issues the POSIX Threads committee
had to face standardizing error handling of the pthread API.
They, in the end, ended up having rewriting the specification such
that each call returned an error code.  In the process, they
created huge incompatibilities between old and new threading
implementations (some of which we are still fighting today).

My point is, you are damned if you do and damned if you don't.

I feel the choices are:
	1) rework error handling such there is a standard
	(preferably thread safe) mechanism for obtaining detail
	error information from each and every API call, or

	2) say it's "implementation specific."

If the choice is 1, I feel that the specification would need
a great deal of work and, hence, should not be progressed at
this time.

If the choice is 2, I believe the specification (with the
modifications recently discussed) could be progressed at
this time.

Option 3 would be to progress the specification as an
Informational RFC while the working group reworks the
specification to removes reliance on implementation
specific mechanisms.

Kurt