Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!adobe!asente
From: asente@adobe.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: XtAddInput returns; error checking in general
Message-ID: <11222@adobe.UUCP>
Date: 16 Feb 91 02:40:34 GMT
References: <64840@brunix.UUCP> <9102141628.AA03719@iris49.biosym.com> <65118@brunix.UUCP>
Sender: news@adobe.COM
Organization: Adobe Systems Inc.
Lines: 17

In article <65118@brunix.UUCP> jhc@irwin.UUCP (James H. Coombs) writes:
>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?

Unless explicitly stated otherwise, you can assume that Intrinsics functions
always return correct data.  Error conditions are handled by calling the
error handler.  An example of a case where an error is indicated by the
return value and not by calling the error handler is XtNameToWidget; the spec
states in section 11.2, "If no match is found, return NULL."  Similarly, you
can't make assumtions about 0 being valid or invalid unless the spec says so.
An implementation would be free to return as an XtInputId an index into a
table, making 0 a perfectly legal return value.

	-paul asente
		asente@adobe.com	...decwrl!adobe!asente