RE: Info reporting in SCE-MI

Hi John,

> Perhaps we can also add something to section 5.3.2.1 that states
> that is expected that user defined SceMiEC error handlers or
> user level code reacting to a returned SceMiEC status indicating
> a fatal error are expected to initiate an abort operation in
> a manner that is properly suited to the application.

In the case of a non-NULL SceMiEC pointer, I think this is too restrictive
as I can easily see a use model where the application passes in a non-NULL
SceMiEC pointer because it wants to probe the interface. For instance,
for the parameter access functions, I would expect to be able to continue
if the parameter I'm looking up does not exist. Or perhaps I want to
write some generic code that could work with multiple testbenches in
different configurations and want to be able to do BindMessage*Port()
without fear of an error handler arboting me because the port does not
exist. With a non-NULL SceMiEC pointer I can detect and handle that
case easily.

Now, perhaps the parameter access example above is bogus because accessing
a non-existent parameter should not be considered a fatal error? But these
functions don't have another mechanism to report errors. Ok, the string
ones could return NULL on a non-existent parameter, but the integer ones
have no way of indicating the error except via the SceMiEC structure.
BTW, relying on the info handler in this case would be cumbersome at best .
. .

Thinking more about this leads me to think we ought to go over all the API
functions and make sure it is well-defined what error cases they should
treat as errors in the SceMiEC sense. If this is not well-defined, there
could be incompatilibities between implementations.

Per
Received on Wed May 26 14:09:31 2004