Re: C++ Exceptions from SCE-MI Error and/or Info Handler?

Per,

My feeling is that this is a perfect example of where the
API should not interfere with the user's application
modeling environment and error handling practices.

The beauty of the errorHandler approach is that
it can be used to adapt the SCE-MI API to a catch/throw
system or not. It is strictly up to the application on
how they implement this handler.

The one thing we may want to say explicity is that
exceptions should *never* be thrown from within the SCE-MI
implementation. That is the whole purpose of the
errorHandler. So that this is handled at the application
layer.

If the application is C++, catch/throws can be used
without problems. If it is C, other schemes can be used.
SCE-MI does not care it just calls the errorHandler
when necessary.

In a SystemC environment you only need catchers at
the top of any given thread. Not at various intermediate
call sites.

In a Raw C++ environment for example you can conveniently
put catchers just inside main.

-- johnS

Bojsen, Per wrote:
> Hi,
>
> the Routed example in the SCE-MI standard installs a custom SCE-MI
> error handler which throws a C++ exception. The SCE-MI standard
> says nothing regarding whether this is allowed or not. However,
> for this to work, the application must be able to wrap an exception
> handler around every call chain that can cause a SCE-MI error
> to happen. This may not always be possible because the application
> may employ various callbacks or UNIX signal handlers for instance.
> These will typically run in a different context and with a different
> callchain so may not be protected by the user's exception handler.
> This will lead to the error either not being visibly reported or
> segmentation faults or other bad behavior.
>
> I'd like to solicit the committee's comments on this issue. At a
> minimum I think the Routed example should follow the SCE-MI standard's
> recommendation (or is it even a mandate) that the error handler should
> abort rather than throw an exception. Or do we want to allow this
> use model? In that case, the standard should be modified to explicitly
> state so as this has implementation consequences.
>
> Thanks,
> Per
>
> Per Bojsen
> Zaiq Technologies
>

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