Per,
Bojsen, Per wrote:
> 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.
johnS:
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.
However, even with this, I still see no need to use it
for the particular scenario you're describing.
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 ?
My experience has been that most applications have an
error handling/logging facility with a certain API.
You definitely *don't* want IP libraries to deal with
this or even know about it since they have no way of knowing
how applications handle errors. That is why SCE-MI error
handling was designed the way it was - to accommodate application
defined error handling in a neutral way. Formating,
printing, logging of messages is completely up to the
user application code.
IP libraries will however want to be able to react to
recoverable errors in their own way. I think we've allowed
for this already (previous e-mails). They
I'm probably still missing what you're trying to get
at however when you speak of IP libraries and error
handling.
Perhaps we can discuss more tomorrow.
>
> 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.
johnS:
I think if we go to my suggestion of using a standard
set of parameters and not allowing vendor defined object
kinds and attributes we bypass this problem. AttributeIntegerValue()
in this case only needs to handle fatal errors as it does now.
This is because NumberOfObjects() can be used in the way
I described before to know if an object exists. If that
object does exist, and it is an object with attributes
clearly defined by the standard, then there's never a reason
to give an invalid attribute name and doing so should
be considered fatal.
>
> > What this implies then is that we would change two things in
> > the explanatory text but not change anything in the API
> > itself.
johnS:
We certainly can clarify this.
>
> Let's discuss this a little further :-)
johnS:
Yes, let's !
>
> 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:53:37 2004
This archive was generated by hypermail 2.1.8 : Wed Jul 14 2004 - 13:53:55 PDT