Re: Recoverable Errors

Per,

OK I'm cleared up now on what you were trying to convey and
I think we're in basic agreement.

I have a few more comments embedded.

Bojsen, Per wrote:
> 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.

johnS:
OK, I guess we're getting subtle points now but let's
consider the SceMi::BindMessageInPort() call for example.

True there are two kinds of recoverrable errors here, namely,
no matching port was found because either 1. the transactor
name was not present, or, 2. the port name was not present.

But from a code flow point of view the application would
probably do only one thing in reaction to either of these
errors. I.e. either error will cause the code to do what it
does when the matching port is not found for whichever of
the two reasons.

If the application wants to convey more specific information
(i.e. which of the 2 reasons for the error) to
the user, that will be clearly spelled out in the message
embedded in the SceMiEC. But from a code flow point of view
a matching port is either found or not found so my assumption
is that we need no more than one enum value to specify recoverable
errors in general rather than having a dedicated enum value for
each distinct recoverable error. The message itself will give
more specifics if and when this info needs to be conveyed to
a user. But from the P.O.V. of the code execution flow that reacts
to the error type we only need one enum per required action
- i.e. what it does on success, what it does on fatal errors, and
what it does on recoverrable errors.

>
> > 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.

johnS:
I agree with this.

>
> > 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.

johnS:
Square brackets. I.e. If there are 0 objects of a given kind
then it is implied that object is not found. This should not
be considered an error of any kind, rather a SceMiSuccess.

>
> > #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?

johnS:
My assertion is that if the code had properly called NumberOfObjects()
before calling this it would have discovered that there were 0
objects of the given kind and should not have bothered to call this
call in the first place. So if it does, it should be considered fatal.

Similarly, NumberOfObjects() returns a proper and valid range for
indexing so there's no excuse for violating that, therefore index
out of bounds should be considered fatal.

Finally, for any given object kind there's a fixed and clearly specified
set of attributes that go with it. If an object of a given kind
exists, the implementation should guarantee that all its attributes
exist. So, again, there's no excuse for specifying in invalid
attribute assuming there was a non-zero return by NumberOfObjects
for the given kind, therefore invalid attributes for that kind
it should be considered fatal as well.

>
> > #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.

johnS:

Same as above and for the remaining attribute calls.

-- johnS

<eom>

>
> >
> > 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
>

______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
Received on Thu Jun 24 09:18:03 2004