RE: Handling of recoverable errors - proposed specification revis ions

Hi John,

> Actually this is not a bad idea and I think it can be changed
> while keeping existing code compatible. We can have
> RegisterError/InfoHandler() return the previous setting.

Ok, let's do :-) So the new prototypes shall be:

  static SceMiErrorHandler
  SceMi::RegisterErrorHandler(
    SceMiErrorHandler errorHandler,
    void *context);

  static SceMiInfoHandler
  SceMi::RegisterInfoHandler(
    SceMiInfoHandler infoHandler,
    void *context);

Add the following sentence to the sentence below each prototype in
the spec:

  If the errorHandler argument is NULL, the default error handler
  will be registered. A pointer to the previous error handler is
  returned. If the previous error handler is the default error
  handler, NULL will be returned.

  If the infoHandler argument is NULL, the default info handler
  will be registered. A pointer to the previous info handler is
  returned. If the previous info handler is the default info
  handler, NULL will be returned.

I added the handling of NULL because it occurred to me that the
spec did not deal with this.

> Library/IP code will want to deal with control flow of
> recoverable errors but don't you think users themselves
> will ultimately want control of how fatal errors
> are handled ?

Yes, of course. I was talking about recoverable errors,
or at least trying to :-)

> I'm probably still missing what you're trying to get
> at however when you speak of IP libraries and error
> handling.

I was thinking of a scenario where some shared code on the
software side could adapt to a family of BFMs that are similar
but still have varying internal organization such as number
and type of ports. If Bind*Port() reports recoverable errors
via the info mechanism and this adaptive code needs to know
whether Bind*Port() failed because the transactor itself is
not in the netlist or a port within it was not present, then
the code would have to register its own info handler while
calling Bind*Port() and look at the info codes returned and
hope that these are distinct for each recoverable error
and, better yet, standardized. The change to
RegisterInfoHandler() would be half of the solution.

> Perhaps we can discuss more tomorrow.

Actually, next Thursday on the 22nd :-)

Per
Received on Thu Jul 15 09:44:40 2004