Per,
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.
I think it is a mistake to try to define a set of specific
enums for each error ahead of time. Each implementation should
provide error info in the message itself using the mechanisms
clearly provided.
We just need a new enum for the recoverable error category
as a whole.
Here's a possibility (which I think it was also my action item
to propose):
typedef enum {
SceMiOK = 0,
SceMiError = 1,
SceMiRecoverableError = 2 // <-- New error type
} SceMiErrorType;
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.
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. The rest are fatal and
can be handled with the existing specification (though possibly
clarified in the descriptions of each function).
Bojsen, Per wrote:
> Hi,
>
> in the last meeting we talked about adding the concept of recoverable
> errors to the SceMiErrorType type. In the discussion we touched upon
> the possibility of enumerating a bunch of recoverable errors that
> should be standardized. I went through the spec and came up with the
> following first cut:
>
> SceMi::Init() [return NULL on error]
>
> Incorrect version argument
> NULL parameters argument [?]
johnS:
I consider both of the fatal errors, not recoverable.
>
> 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)
>
> SceMi::BindMessageOutPort() [return NULL on error]
>
> Transactor not found
> Port not found
> transactorName argument NULL [?]
> portName argument NULL [?]
johnS:
Same as above.
>
> SceMiParameters::SceMiParameters()
>
> Parameter file not found [?]
> paramsFile argument NULL [?]
johnS:
Both fatal (return SceMiError)
>
> 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.
#2 is fatal, not recoverable.
>
> 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
#4 fatal
#5 fatal
Note: All these are already fatal as per comments in .h file.
>
> 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
>
> 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.
>
> 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.
>
> SceMiMessageData::Set() [void return value, do nothing on error]
>
> Index out of bounds
johnS:
Fatal.
>
> SceMiMessageData::SetBit() [void return value, do nothing on error]
>
> Index out of bounds
johnS:
Fatal.
>
> SceMiMessageData::SetBitRange() [void return value, do nothing on
> error]
>
> Index out of bounds
> Index + range out of bounds
johnS:
Fatal.
>
> SceMiMessageData::Get() [return 0 on error]
>
> Index out of bounds
johnS:
Fatal
>
> SceMiMessageData::GetBit() [return 0 on error]
>
> Index out of bounds
johnS:
Fatal.
>
> SceMiMessageData::GetBitRange() [return 0 on error]
>
> Index out of bounds
> Index + range out of bounds
johnS:
Fatal.
>
> That's it. I think the above is a good start.
>
> Enjoy,
> Per
>
> --
> Per Bojsen Email: <bojsen@zaiqtech.com>
> Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com
> 78 Dragon Ct. Tel: 781 721 8229
> Woburn, MA 01801 Fax: 781 932 7488
>
-- johnS
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient. Any review, reliance or distribution by others or
forwarding without express permission /\
is strictly prohibited. If you are /\ | \
not the intended recipient please | \ / |
contact the sender and delete / \ \
all copies. /\_/ K2 \_ \_
______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
Received on Wed Jun 23 06:10:42 2004
This archive was generated by hypermail 2.1.8 : Wed Jun 23 2004 - 06:10:44 PDT