paulruizendaal wrote:

>I was wondering if we could learn from error handling in COM,
>including variants like XPCOM and UNO. COM components have to deal
>with multi-threading and multiple exception handling models.
>
>It seems to me that the COM model combines the suggestions of Nicolay,
>Jim and Dmitry, building on the merits of each one.
>
>(i) in first instance, errors are reported in a scalar return value
>(a HRESULT, could be GDSCODE for us);
>(ii) following an error, the application calls a GetError type
>function, which returns a thread-specific value;
>(iii) the thread-specific value is a pointer to an error object in COM
>format
>
>
>

This means that some state is returned by the API call as a status,
other state must be maintained for arbitrary periods as thread data, and
still more state is returned by a GetError function. It is far simpler
pass an error object to a method on a client supplied handler object and
be done with it. All available context is made available at once. The
error object can be destroyed immediately following return from the
error handler and no thread data needs to be maintained. It gives the
client a squeeky clean mechanism to encapsulate his own error process
with no addition per-API call process required beyond a test to see if
an error occurred, which, in languages that support exceptions, will
throw an exception.

I intensely dislike globals for a number of reasons. One is that it
leads to really sloppy programming. Another is that really bad
programmers can't program without them, and banning globals effectively
bans really bad programmers. Thread specific data is global with all
the problems of globals plus a very high overhead. They are necessary
to implement the threading system itself, but I would like to outlaw
their use for any other purpose. Defining an API that is dependent on
thread specific data is, in my opinion, a terrible idea.

That said, you could easily implement a client error handler with almost
the semantic you want, missing only the return code, which you could get
with a subsequent call the error handler. I don't think you really want
to do that, but you could.

I'm reasonably satisfied with the client supplier error handler
mechanism. It's simple, thread safe, extensible, language independent,
efficient, and meshes well with languages that support exceptions. I
don't want to stop debate, but I think we have a solution.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376