proposed minor change to iBase

[Carl Ollivier-Gooch]

Jason Kraftcheck wrote:
> Mark Miller wrote:
>> I don't have any experience/history of this enum within TSTT/ITAPS 
>> context.
>> 
>> However, I recall having a similar library setting in another
>> project. It was designed to support two modes of interaction with
>> the library...
>> 
>> 1. Test the return value (or error code in case of ITAPS) where an
>> application was coded like so...
>> 
>> iMesh_newMesh(...&err); if (err != iBase_SUCCESS) do something for
>> error
>> 
>> 2. Try/catch mode where the application was coded like this...
>> 
>> TRY { iMesh_newMesh(...); } CATCH { do something for error } ENDTRY
>> 
>> 
>> The calling application would TELL the library how to behave;
>> either throw or return with error code set. The library would then
>> behave as the caller wished. However, we wrote the library from
>> scratch with this in mind. Retro-fitting existing implementations
>> -- if they were not already set up for this -- may be more trouble
>> than its worth.
>> 
>> Nonetheless, I think this kind of control is useful as it permits
>> both programming styles.
>> 
> 
> That's interesting but not applicable here:  a) no C standard yet
> includes exceptions and b) the values for the enum are: enum
> ErrorActions { SILENT,                 // does nothing, not
> recommended WARN_ONLY,	      // prints something, but nothing else 
> THROW_ERROR             // throws an exception };

This is definitely a hangover from the SIDL days, where the interface
could claim to throw an exception, with Babel converting it to a return 
value in all languages except C++ and Java.

I agree with Jason that this is something that we can cheerfully do 
without.

Also, it got me thinking about iMesh_getDescription, which I looked up.

There are two possible interpretations here:

1.  An app hits an error code and asks for a description of it; the 
implementation has a string for each error code.  This would presumably 
take a "/*in*/ int err".

2.  An app asks what just happened; the app has the error code and a 
(possibly context-specific) error description stored somewhere, and 
returns those.  This requires a "/*inout*/ int *err", which is what we have.

The former is what I'd assumed this function does, but the signature 
suggests the latter.  So which do we mean?  And if the latter, why 
bother returning the error code, which the app already has as a side 
effect of the function call, and has to check to know whether to request 
a description anyway?

And in any even, the function signature suggests that the app is going 
to pass in a pre-allocated char array of size descr_len, or at least, 
that's the obvious interpretation of the C.  But a Fortran 
implementation presumablywon't like that much.

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Associate Professor                                 Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------