Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!brunix!irwin!jhc
From: jhc@irwin.uucp (James H. Coombs)
Newsgroups: comp.windows.x
Subject: Re: XtAddInput returns; error checking in general
Message-ID: <65118@brunix.UUCP>
Date: 15 Feb 91 14:44:33 GMT
References: <64840@brunix.UUCP> <9102141628.AA03719@iris49.biosym.com>
Sender: news@brunix.UUCP
Reply-To: jhc@irwin.UUCP (James H. Coombs)
Organization: IRIS - Brown University
Lines: 27

In article <9102141628.AA03719@iris49.biosym.com> pete@iris49.UUCP (Pete Ware) writes:
>jim> But, I see a subsequent call to XtNew(), which calls malloc().
>jim> XtAddInput() then uses the result without checking for a valid
>jim> pointer.  It is this pointer that is returned as the XtInputId.
>
>XtMalloc() calls XtErrorMsg() if the allocation fails.  For better or
>worse, XtErrorMsg() is for fatal errors and the application exits.  In
>other words, XtMalloc() exits instead of returning NULL.

I see that now, thanks.  But that still leaves the issue of testing a
table for an "unset" value.  Is it appropriate for me to test for
NULL?  I know that XtAddInput() will never return NULL, but I don't see
that in the documentation.  That means that the implementation could be
changed to return some other datatype--in which 0 might be valid--and
my code will break.

The same problem comes up with XtAppAddWorkProc().

I am looking for a general principle.  Is it that there are no error
returns?  Is it that errors always call the fatal error handler?  And,
if that is true, is it that all data is opaque---that there is no value
that I can test for to see whether or not something has been set?

(I pursue these questions because we are trying to standardize our
coding style, including error handling.)

Thanks.  --Jim