At 10:01 PM 3/29/00 -0600, sam th wrote:
>1 UT_FAKEOK - This would represent an OK that didn't mean anything, as in,
>there was only one return statment, and it returned OK. This has a
>serious boolean testing problem (0 is taken), and cannot be implemented if
>that is not solved.
Could you give an example of when this distinction would be useful? I can't
imagine ever using it instead of a vanilla OK.
>2 UT_REALLY_BAD_ERROR - This would go along with
>UT_ASSERT(UT_SHOULD_NOT_HAPPEN). The code would look like
>
>if(fatalErrorHasOccured)
>{
> UT_ASSERT(UT_SHOULD_NOT_HAPPEN);
> return UT_REALLY_BAD_ERROR;
>}
The two have nothing to do with each other. If you're seeing usage like
this, then somebody's blurred the semantics of UT_SHOULD_NOT_HAPPEN.
The usual semantics are for use in the default case of a switch statement
which we never expect to use. It's a robustness thing -- a reminder to
whoever's running debug builds that an unexpected case cropped up. It's not
necessarily a fatal error, but it should be looked at. In most such cases,
no error propagation is necessary.
>Neither of these is really neccessary, but I just wanted to see what
>people thought of them.
I'm not sold on either one yet. However, we may want to introduce a error
code for UT_BADARGS.
Paul,
design grouch
