Handling of recoverable errors - proposed specification revisions

Per,

I had started the rewording of the section 5.3.1 on error handling
to add an enum type for recoverable errors. However, the more I
thought about it, the more I'm wondering if we should slightly
revise what we had discussed earlier w/ regard to the enum.

This existing paragraph in section 5.3.1 got me thinking:

"This error handling facility only supports irrecoverable errors.
This means if an error is returned through the SceMiEC object,
either via a handler or a return object, there is no point in
continuing with the co-modeling session. Any calls that support
returning a recoverable error status need to return that status
using a separate, dedicated return argument."

My thinking now is that this paragraph should still apply. That
is, recoverable errors are conveyed from a control flow point of
view by a means other than the SceMiEC object. In other words,
via a separate argument or function return value.

SceMiMessageInPortProxy *
SceMi::BindMessageInPort()

is a perfect example. As we had discussed, we've all agreed that
not finding a port should be a recoverrable error. However,
after re-considering, the means of indicating this recoverrable
error should not be through the SceMiEC. I think the quoted
paragraph above should continue to strictly hold true.

So the question becomes, how do we convey a recoverable error
of a port not found to the user through an informative message,
and, as importantly, how do we allow for the program control flow
to react properly to a recoverable error ?

The good news is that we already have mechanisms that can
handle both of these issues, both in the way the BindMessagePort
function itself is already defined, and in our SceMiIC information
message mechanism. So,

1. For control flow: BindMessagePort() can return a NULL if
     the port is not found. This provides control flow a way
     to react to the recoverable error of a non-existent port.
     and also complies with the quoted paragraph above.

2. To convey the information to the user: The non-existent
     port can be announced via an info message that has the
     type SceMiNonFatalError (which already exists).

What this implies then is that we would change two things in
the explanatory text but not change anything in the API
itself.

---------------------------------------------------------------
Modification 1:
5.3.2.2 Class SceMiIC - informational status and warning handling (info handling)

Reword last paragraph as follows:

"An additional category, called SceMiNonFatalError, can be used for two
purposes:

"1. To log all error conditions leading up to a fatal error. The final fatal error
message shall always be logged using a SceMiEC structure and SceMiErrorHandler
function so an abort sequence is properly handled (see 5.3.2.1).

"2. To convey information about recoverable errors. As described in section
5.3.2.1, recoverable error status is returned to the caller via explicit
call arguments or return values. However, message text conveying information
about the reason for the recoverable error can be passed to the info handler
using the SceMiNonFatalError message type. All possible recoverable errors
in the SCE-MI API are explicitly noted in the specification for
each API function where applicable. Other than where so noted,
all other errors are assumed to be fatal and are handled via the
SceMiEC structure described in section 5.3.2.1.

"In addition, the info message can optionally be tagged with a unique identifying
integer specified in the Id field."

---------------------------------------------------------------
Modification 2:
5.3.3.4 Message input port proxy binding

Change last sentence of 1st paragraph from,

"It shall be an error if no match is found."

to,

"It shall be a recoverable error if no match is found. This shall
be indicated with a NULL pointer returned. It will also result
in a call to a SceMi info message handler if one as been
registered (see 5.3.2.2)."

---------------------------------------------------------------
Modification 3:
5.3.3.4 Message output port proxy binding

Change last sentence of 1st paragraph exactly as
described above.

-- 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 Thu Jun 24 16:44:58 2004