Re: Info reporting in SCE-MI

Shabtay,

Shabtay Matalon wrote:
> The SceMiEC *ec argument allows the caller of any SCE-MI class to
> determine if errors will be conveyed to the caller by using the non-NULL
> pointer or to an error handler by using the NULL pointer (either the
> default error handler or the one that was registered).
>
> However, if I properly understood section 5.3.2.2 that deals with the
> SceMiIC class, info type messages cannot be controlled to go back to the
> caller and will only be conveyed to an info handler, either the default
> error handler or the one that was registered.
>
> If I further look at which types of errors and information is provided
> in each case, the error handling facility is stated to support
> "irrevocable errors" and thus the non-Null pointer option is of little
> use as the application needs to report the error and abort.
>
> To the contrary, as the info type messages should be handled at the
> discretion of each caller, I would have expected that the caller would
> receive the info type messages and thus the non-Null pointer option will
> be of higher value if applied to info type messages. In particular this
> is useful given the 3 enumerations of info types that the caller may
> branch upon given the context of the call.
>
> Have I misunderstood the intended use of these classes?
>
> Can one explain the current logic behind providing the non-NULL pointer
> option for irrevocable errors and not for info handling? Is this an
> issue worth reconsidering for amending in the spec?

The reason we support the non-NULL pointer option being passed to the
call is to support legacy C programming style where every call returns
its status and it is up to the calling code to deal with errors on a call
by call basis. Traditional C APIs, such as many Unix API calls, tend to
pass an error status as the return of every call.

Given that such archaic error handling tends to have been replaced
with more modern error handlers and exception catching/throwing
mechanisms, use of NULL pointers on each SCE-MI call is by far the more
recommended way of doing things.

However, the feeling was that there may be old-style C program applications
that may wish for statuses to be returned on each call and do proper
error abort handling after the call returns in that traditional way.
That is why we added support for this to the specification.

As for info messages, we felt that an info message handler was a cleaner
way to handle them since, unlike abort handling of fatal errors, info
messages should not generally affect the flow of execution after call
returns.

-- johnS

>
> Thanks,
>
> Shabtay
>
>
> -------------------------------------
>
> Shabtay Matalon
> Solution Architect
> Solutions R&D, SFV
> Phone: (408) 428 5081
> email: shabtay@cadence.com
>
>
>

-- 
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________