Claudio Valderrama C. wrote:

>Jim Starkey wrote:
>
>
>>I'm reasonably satisfied with the client supplier error handler
>>mechanism.
>>
>I don't understand the context.
>What was the original purpose of the post? To inform the list members that a
>decision had been taken? To cause technical discussion? In the second case,
>how could it happen if the original proposer came here with the idea cooked
>and set in stone? Who would waste time arguing in favor of or against it?
>Apparently Dmitry Sibiryakov bit the bait and lost his time.
>
>
>

Claudio, thanks for the history lesson. I think we agree that process
is as important as detail, especially in an open source project with
creative people of strong will. But let me give you a recap.

Sometime back, I said that I though we needed a new primary interface to
replace the dreadfully inefficient DSQL interface. I believe I said
that the requirements for the new primary interface should be:

1. Callable by most languages, i.e. 'extern "C"'
2. Supports the existing DSQL interface as a layer
3. Supports the existing IscDbc interface as a layer
4. Extensible, efficient, and readily adaptable to the remote protocol.

I went on to say that I thought the new primary API should have the
following characteristis

1. Object oriented for extensibility
2. Functional, in the sense that each call returns a single value
3. Errors are reported as exceptions

The third characteristic is dictated the the second.

Nickolay raised a valid objection that a language specific exception
unwind mechanism would not work cross languages to the degree of
corrupting the stack. To address this problem, I came up with a variant
that uses a client supplied error handler object passed as a parameter
to each API call. This allows an error to be reported asynchronously
even though the call return synchronously.

Paul R. proposal an alternative style of error reporting used by some
COM systems. The style violated the "functional" characteristic I
wanted for the primary API, but could be readily emulated by a canned
error handling class.

I am satisfied that we have an existence proof of an error reporting
mechanism that meets the requirements and desired characteristics for
new primary API.

As I said earlier, it is my intention to write up and propose a
replacement primary API for Firebird. There will be all the time in the
world to pick it apart, argue about it, find problems, fix problem, and
vote it up or down long before any implementation work is started, if ever.

The process that I believe leads to good design has these steps:

1. There is agreement on requirements. This is too often skipped.
Without a clear understanding of requirements, there is no way to
judge a prospective design.
2. An individual produce a design. Or maybe two or three individual
produce independent designs. I don't like design by committee
3. Prospective designs are weighed against the requirements. This
often leads to a restatement of the requirements and an iteration
(this is a very good thing). Problems are found, imaginations are
kick-started, alternatives proposed.
4. The design iterates until the designer is convince it is complete
5. The project does a final analysis with a thumbs up or a thumbs down.

I think discussion of the requirements and important characteristics is
useful, healthy, and will lead to a better design. When I propose that
design, it will be a design that I believe meets the requirements, the
desired characteristics, and is internally consistent. Then we pick it
apart.

I'm perfectly happy to continue the discussion of error reporting in a
hypothetic new primary API. I do have a scheme that I believe works.
If something better shows up, I'll adapt it.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376