RE: Handling of recoverable errors - proposed specification revis ions

Hi John,

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

Yes, that is an obvious choice and what I would expect.

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

While this sounds reasonable, I don't think this is useful for
library/IP code. The reason being that the library/IP code has
no control over the info callback function. Sure, it could
install its own when it is about to call one of the functions
that may convey recoverable errors using this mechanism, but
there is no way for it to re-install the original handler
after the call. The current error and info handler API is
flawed in this respect. For instance, the standard C library
signal() function which is used to install a signal handler
returns the previous signal handler. This allows the
code to install a temporary handler during some critical
section of code and then reinstall the original handler upon
exit of this code. The SCE-MI Register(Error|Info)Handler()
methods do not support this use model as they return void.

So, since the only way info messages are conveyed are through
an info handler, there is no way for library code to use this
mechanism.

Also, there is the issue of AttributeIntegerValue() which
cannot indicate a recoverable error with its return value.
And the Override*() methods have no return value, so they
cannot indicate errors that way either.

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

Let's discuss this a little further :-)

Thanks,
Per
Received on Mon Jun 28 08:06:46 2004