proposed minor change to iBase

[Mark Miller]

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.

Mark

On Tue, 2009-11-03 at 16:44 -0600, Jason Kraftcheck wrote:
> The ErrorActions enum doesn't seem to be used either the C or SIDL bindings.
>  I think that it should therefore be removed.  The alternative is to add one
> or more functions to allow setting of this property.  However, disabling the
> returning of error codes globally for all errors seems like a recipe for
> disaster.  And when one considers the possibility of several components
> communicating through a shared iMesh instance, the possibilities seem
> particularly horrible.
> 
> - jason
> 
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86 at llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)