RE: Recoverable Errors

Hi John,

> My recollection was that we were just going to an enum
> value for all categories of recoverable error rather
> than predict each possible recoverable error type.

You are right, but I think you misunderstood what I was trying
to do. See below.

> I think it is a mistake to try to define a set of specific
> enums for each error ahead of time.

You misunderstood my intentions. When I said `enumerate' I
did not mean `create a C/C++ enum type' but merely to list
common errors that all implementations should be able to
catch and report the same way as recoverable errors.

However, the reluctance to standardize error codes can lead
to difficulties in writing portable SCE-MI code. For instance,
if when we introduce the recoverable error mechanism for
BindMessage*Port(), you have below accepted two kinds of
recoverable errors for each of these functions. Without
standardizing the error codes, you cannot write a portable
application that can distinguish between the two error cases.
Of course, that also goes for other types of errors.

In summary, if we do not standardize error codes a portable
SCE-MI application cannot do much more than report the error
or blindly react to it.

> Here's a possibility (which I think it was also my action item
> to propose):

I have no issue with your proposal.

> But we also agreed to outline specifically what were recoverable
> errors for the various functions involved. Then, in the
> description for those functions identify which conditions
> cause a return of "SceMiRecoverableError" in the SceMiEC.

This is precisely what I was intended to do. Rather than having
some vague discussion at the conference call I just went through
the API and found all cases that I thought could reasonably be
listed as recoverable errors.

> I've embedded some specific comments to your suggested recoverable
> errors below. So you'll see that of all the things you mention,
> only port bind attempts are recoverable.

Hmm, what about the parameter access API? It seems unreasonable
to make failed lookups fatal errors . . .

> SceMi::Init() [return NULL on error]
>
> Incorrect version argument
> NULL parameters argument [?]

> I consider both of the fatal errors, not recoverable.

I'm OK with this.

>
> SceMi::BindMessageInPort() [return NULL on error]
>
> Transactor not found
> Port not found
> transactorName argument NULL [?]
> portName argument NULL [?]

> johnS:
> The 1st 2 are recoverable (return SceMiRecoverableError)
> The 2nd 2 are fatal (return SceMiError)

OK.

>
> SceMi::BindMessageOutPort() [return NULL on error]
>
> Transactor not found
> Port not found
> transactorName argument NULL [?]
> portName argument NULL [?]

> johnS:
> Same as above.

OK.

>
> SceMiParameters::SceMiParameters()
>
> Parameter file not found [?]
> paramsFile argument NULL [?]

> johnS:
> Both fatal (return SceMiError)

OK, I accept that.

>
> SceMiParameters::NumberOfObjects() [return 0 on error]
>
> Object kind not found [actually I think it is better just to
> return 0 in this case, i.e., not an error]
> objectKind argument NULL [?]

> johnS:
> Agree on #1.

You agree on the comment in square brackets, i.e., that the function
should return 0 in this case? Please clarify.

> #2 is fatal, not recoverable.

I'm OK with that.

>
> SceMiParameters::AttributeIntegerValue() [return 0 on error]
>
> Object kind not found
> Index out of bounds
> Attribute not found
> objectKind argument NULL [?]
> attributeName argument NULL [?]

> johnS:
> #1 fatal
> #2 fatal
> #3 fatal

Why?? This is one of the functions for which I orignally thought
recoverable errors would be useful for. Basically, I think a
failed lookup should be considered a benign error so that a use
model where the user passes a non-NULL SceMiEC into this function
and checks the error code afterwards can be implemented. If
failed lookups were considered fatal errors, the application
is obliged to exit/abort/throw an exception, and cannot distinguish
between benign lookup failures and more serious problems.
BTW, in the last meeting you agreed that these should be considered
recoverable errors. What happened?

> #4 fatal
> #5 fatal

Ok, I can accept that.

> Note: All these are already fatal as per comments in .h file.

We can always change that :-)

>
> SceMiParameters::AttributeStringValue() [return NULL on error]
>
> Object kind not found
> Index out of bounds
> Attribute not found
> objectKind argument NULL [?]
> attributeName argument NULL [?]

> johnS:
> Same as above

My comments above apply here as well.

>
> SceMiParameters::OverrideAttributeIntegerValue() [void return value]
>
> Object kind not found
> Index out of bounds
> Attribute not found
> objectKind argument NULL [?]
> attributeName argument NULL [?]

> johnS:
> Same as above.

My comments above apply here as well.

>
> SceMiParameters::OverrideAttributeStringValue() [void return value]
>
> Object kind not found
> Index out of bounds
> Attribute not found
> objectKind argument NULL [?]
> attributeName argument NULL [?]

> johnS:
> Same as above.

My comments above apply here as well.

>
> SceMiMessageData::Set() [void return value, do nothing on error]
>
> Index out of bounds

> johnS:
> Fatal.

OK.

>
> SceMiMessageData::SetBit() [void return value, do nothing on error]
>
> Index out of bounds

> johnS:
> Fatal.

OK.

>
> SceMiMessageData::SetBitRange() [void return value, do nothing on
> error]
>
> Index out of bounds
> Index + range out of bounds

> johnS:
> Fatal.

OK.

>
> SceMiMessageData::Get() [return 0 on error]
>
> Index out of bounds

> johnS:
> Fatal

OK.

>
> SceMiMessageData::GetBit() [return 0 on error]
>
> Index out of bounds

> johnS:
> Fatal.

OK.

>
> SceMiMessageData::GetBitRange() [return 0 on error]
>
> Index out of bounds
> Index + range out of bounds

> johnS:
> Fatal.

OK.

So it looks like we so far agree on BindMessage*Port() and
perhaps I can convince you to add the parameter access API
to the list of methods that can generate recoverable errors?

Thanks,
Per
Received on Wed Jun 23 07:37:53 2004