RE: Recoverable Errors

Hi John,

> [Discussion of problems with the proposed recoverable error
> code in SceMiEC elided].

I agree with most of your observations. I am not married to
the specific proposal of adding the recoverable error code
to SceMiEC. My main concern is to be able to write code that
does not throw fatal errors when it is not necessary.

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

I think we've converged here on most issues except the parameter
access which I'll comment on further below.

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

Agreed. We should write this requirement down somewhere :-)

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

Well, you can't locally distinguish between `transactor not found'
and `port not found' when Bind*Port() returns NULL to indicate
a recoverable error. Even if one passed the SceMiEC object,
it would be set to SceMiOK and you can not use the error codes
to distinguish between the two cases even if you were willing
to rely on implementation specific codes.

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

Sure, the IP module that wants to bind some ports could scan
the parameter database to find what ports are available, but that
to me seems a lot more cumbersome than just trying the Bind*Port()
call and see what happens. This is of course only a pragmatic
issue, but if something is cumbersome to do with an API it is
likely that it won't be done or will be done incorrectly.

> Therefore, one
> can argue that the only error handling necessary is that for
> irrecoverable errors.

I am not sure what you are getting at here. Isn't this just a
matter of what you call things? I guess it depends on what you
mean when you say `error handling'.

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

While this sounds compelling, several implementations I know
of have taken advantage of implementation defined parameters . . .
But I can't find a good theoretically sound argument for
allowing implementation defined parameters as it leads to other
questions such as namespaces and how to avoid name collision
when/if new standard attributes are added in the future.

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

Yes, there is that as well. But this argument could be used
against implementation defined error and info codes as well :-)
You were previously opposed to standardize error and info
codes :-)

> Restricting it to a standard set guarantees portability.

It is hard to argue with this statement.

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

Agreed, except for the subtelty that NumberOfObjects() = 0 would
then mean either `no objects of a defined object kind' or
`object kind undefined'. Now, I suppose I would have to come up
with an example where this distinction makes a difference?

One (ugly, depending on your point of view) way around this is to
change the return type of NumberOfObjects() to int and specify
that NumberOfObjects() will return -1 on `object kind undefined'.

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

Yes.

> In retrospect, so far in our implementation we've had no need
> to expand the SCE-MI parameter set.

This is not surprising given that the spec was based on your
implementation . . . But as the spec is now, it virtually
recommends that the implementation puts implementation
specific attributes in the parameter file . . . Where did this
language come from?

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

Right, probably that is a good idea. Other standards have dealt
with this by creating registries where vendors can register
their implementation specific attribute and object names to
avoid name collisions. But there does not seem to be a real
need for that here, at least not at this point.

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

I agree with this.

The above raised a couple of questions regarding the Bind*Port()
methods and perhaps the parameter API as well. Assuming SceMiEC
is not changed, we have agreed that Bind*Port() will return NULL
when a port is not found and *not* throw a fatal error. This
means, regardless of whether or not a non-NULL SceMiEC is passed,
Bind*Port() will return and the error handler will not be called.

My question is then, given that this is a recoverable error,
are we now mandating that the implementation should flag an
info message of type SceMiNonFatalError? The problem I have
with this is that this could lead to excessive logging that
could easily confuse users. Of course, a way around this would
be possible if we change the RegisterInfoHandler() method as
discussed in previous email, as the code could bracket the
Bind*Port() calls and other calls that might flag non-fatal
recoverable errors with the registering of a dummy info handler
that would just throw the message away. This is not an
elegant solution, thouhg, as it might throw away important
info messages.

So, should we simply specify that Bind*Port() returns NULL
on port not found and mandate that no error or info message
is thrown? This would completely eliminate the possibility
of locally distinguishing between `transactor not found'
and `port within transactor not found', though.

Per
Received on Thu Jul 15 09:25:27 2004