RE: Info reporting in SCE-MI

John,

Thanks for the response. Please see my notes interspersed.

Shabtay

>
> 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.
[Shabtay] Ahhhaa. I new there might be a reason. This makes sense.
>
> 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.
[Shabtay] While the SCE-MI spec indicates that EscMiErrors should only support irrecoverable errors, I haven't seen in the spec a requirement that info messages would not cause an abort. I believe that this is left to the application which may result that one implementation behaving differently than others, all being scemi compliant.
A second order of magnitude issue is that categorization of what is considered a SceMiError (aka fatal error) and what is considered Info, warning and NonFatal error is also left to the implementation.

If agreed that the first topic is a loophole, maybe it should be addressed by more precise language in the section 5.3.2.2 section of the SCE-MI spec.

As to the second issue, I think that this deserves thought if the spec needs to be tightened. It may well be good enough to leave it to each implementation granted that the affect on the flow of execution after call returns is not affected.
What do you think?
>
> -- 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
> ________________________________________________________________
Received on Wed Apr 7 16:27:28 2004