Re: Recoverable Errors

Per,

Bojsen, Per wrote:
> Hi John,
>
> > OK I'm cleared up now on what you were trying to convey and
> > I think we're in basic agreement.
>
> Good :-)
>
> I have some responses to your comments below.
>
> > 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.
>
> I agree this is subtle and we are probably ahead of our time
> in the sophistication of SCE-MI IP, but I can envision IP code
> that could really take advantage of knowing the distinction
> of which recoverable error was caused. For instance, I can
> envision a family of transactors/BFMs that are related but
> have slightly different combinations of ports. If they are
> sufficiently related they can be served by the same C/C++
> SW-side code, that is, substantially the same with some
> branches relative to what ports were found. So knowing that
> the recoverable error is `port not found' is helpful to code
> such as this as it would use it to find out what sub-flavor
> the particular transactor it's communicating with is. In
> this case, `tranactor not found' is a more serious error,
> that could be used by the software layer to convey an error
> to a higher layer.

johnS:
But my feeling is that you can deal with this on a call by
call basis and that each call intelligently returns a status
that gives code execution flow a clear direction. I still
question whether these things belong in the SceMiEC.

In fact, I think it is awkward to use SceMiEC in this way
because it means that sometimes you need to use SceMiEC
for checking recoverable error status and other times you
pass NULL SceMiEC because you want the error handler
to handle errors.

I think it is much cleaner to have one way of handling
fatal errors and, for all recoverable errors,
have each call be defined to indicate recoverable error
outcomes via explicit call arguments, or explicit meanings
of existing call arguements (the way we do now). This approach
carries nicely into the future because future calls can
easily be designed to allow for this.

Meanwhile, the current mechanism can continue to work
in its two modes for handling fatal errors:

1. Pass NULL SceMiEC and use error handler.

OR

2. Pass non-NULL SceMiEC and react to its return value.

If we now overload SceMiEC to handle non recoverable
errors as well, it becomes ambiguous which of 1 or 2
above you use. In fact, you can no longer use #1 if
you also need to check for recoverable errors. And now
you have inconsistent code because some needs to use #1
and the rest needs to use #2. Worse yet, where you
use #2 to check recoverable errors, you have to now
add inlined checks for the fatal errors where before you might
have been using a single error handler for this.

One of the nice things about the interface now is that #1
allows you to write very clean readable code with a minimum
of inlined error and status checking.

Users will want to be able to continue to use #1 without
having to revert to #2 only in the cases where recoverable
error checking has to be done.

Today that is not required because all recoverable errors
are handled with other call parameters or return values.

We should guarantee that in future enhancements of
the specification, this continues to remain the case.

>
> On the other hand, `transactor not found' would be an error
> useful to distinguish families of testbenches at the layer
> of the SW-side that configures the SW-side of the testbench.
>
> True, you can do both of the above with a collapsed recoverable
> error indication, but it becomes more cumbersome and the code
> can do less on its own. I think the latter becomes more
> important if we want to promote SCE-MI based IP versus standalone
> monolithic SCE-MI applications.
>
> > 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.
>
> This is OK for reporting to the user but not useful to the code
> as the error codes and messages are implementation defined and
> likely to change from release to release.
>
> I'd like to explore the question of whether we should collapse
> recoverable error codes or not at the next meeting.
>
> > 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.
>
> Even given that, I still prefer the recoverable error approach
> especially if I'm given an indication of which recoverable error
> it is. It is just more convenient to just call the attribute
> lookup function than first have to call NumberOfObjects() and
> then divert depending on the result. But I can go either way
> on this one.

johnS:
My concern is that you're taking what is already an unambiguous
interface and complicating by providing alternative means of error
checking.

If, in the current mechanism we were not providing all that
is necessary for proper recoverable error handling, that would
be one thing but that is not the case.

In other words, using the current interface for the parameter
database it is possible to write code that completely and
unambiguously checks for recoverable errors. Therefore, one
can argue that the only error handling necessary is that for
irrecoverable errors.

>
> > 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.
>
> Same comment as above.
>
> > Finally, for any given object kind there's a fixed and clearly
> > specified set of attributes that go with it.
>
> No, I think this is incorret. There is a fixed *minimum* set
> of attributes, but the spec allows the implementation to add
> attributes and objects of its own. It is easy to envision
> even portable SCE-MI code accessing implementation specific
> attributes. For example, different implementations might use
> such attributes to store information that allows the application
> to fine tune its performance or change aspects of how the
> implementation handles messages. So highly tuned SCE-MI IP code
> might want to probe for different attributes to find out if it
> is running under a particular implementation.

johnS:
I wonder if we should tighten this up to restrict it
to just the necessary parameters to characterize the interface
which is what the pre-defined ones do.

My concern is that as soon as you allow implementation defined
parameters, you allow for unportable code.

Restricting it to a standard set guarantees portability.

>
> Another aspect is that the current defined standard set of
> attributes may be augmented in the future and some users may
> want to write code that can run on several versions of SCE-MI.

johnS:
If standard object kinds are augmented in the future then we can
assume newer code that accesses new object kinds on older interfaces
well see NumberOfObjects() = 0 in those cases so, there's still
no need for expanded error status.

>
> If all you get is a fatal error on looking up a non-existent
> attribute, then the application code has no way of telling
> what the error really was. Ok, it could just assume that
> it was just a benign fatal error (isn't that an oxymoron, anyway?)

johnS:
Again, I think if we restrict the parameter set to only that
defined in the standard we resolve this. Do you agree ?

That is not to say we cannot expand the standard parameter
set in future revisions. But restricting parameters to the
standard set guarantees that code is portable among vendors.

In retrospect, so far in our implementation we've had no need
to expand the SCE-MI parameter set. We handle all vendor
specific parameters in a separate config file. This is probably
the way it should be anyway since once cannot possibly predict
all the different possible vendor specific parameters within
that standard. Therefore, my feeling is that the specification
should not concern itself with this.

> such as attribute not found and continue, but then if it was
> really a true fatal error it is likely to get more and perhaps
> the application will segfault eventually without giving the
> user a good indication of what went wrong.

johnS:
I guess I'm looking for a "closed system" where there is
minimal ambiguity. We already handle all possible fatal errors.
And all possible recoverable errors are handled on a call by
call basis for each of the calls where it is relevant. I would
prefer to keep this philosophy for future enhancements of the
interface.

>
> What do you think?
>
> Thanks,
> Per
>

-- johnS

______________________________/\/ \ \
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 Jul 14 13:18:03 2004