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

Per,

Some comments embedded.

Bojsen, Per wrote:
> Hi John,
>
> this is a belated reply, but I hope you remember the issue.
>
> > Throwing an exception is a common (and very clean) means of
> > aborting. This should not be prevented. One of the big
> > advantages of catch/throw is that you can define the abort
> > sequence at one location at the very top of the program
> > where it makes sense.
>
> I agree that C++ exception handling is a good mechanism.
>
> > Aborting inside a single catch block tends to be a lot more
> > elegant than, for example, buried calls to exit(). Cleanup
> > and graceful exits tend to be easier from a top level
> > location in the program.
>
> I completely agree with you on this.
>
> However, my concern is that it is possible for an application
> to call the SCE-MI error handler from outside the normal call-chain
> of the application. If the error handler throws an exception in
> this case, the exception handler the user installed will not catch
> the exception. An example of how this might occur is if the
> implementation employs interrupt handlers, signal handlers, or
> callbacks that execute with a different stack than the user's
> application code.

johnS:
My feeling on this is as follows: anywhere where the user wishes
to use exception throwing in their error handler, they need to
be sure to provide catch blocks in all possible call chains
under which this handler can be called. Generally these can
fall under 3 categories:

1. Under main() and all its descendants - which is the most common
2. Under a signal handler - as you suggest above
3. Under independent threads of some threading kernel such as
    SystemC.

In all cases, the root of the call chain requires a catch block
to properly handle throws.

So, for example in #2, if your signal handler intends to call
SCE-MI API functions, it should do so inside a catch block if
indeed the user wishes to handle the possiblity of errors and
they have chosen to use exception throwing in their error
handler.

Although, my feeling is that generally signal handlers should be
quick in and out operations that may set a few flags that other
mainstream code (i.e. in the main() call chain) monitors, and
immediately return. The maincode itself should then be calling
SCE-MI API functions that might result in errors. But if indeed
it is truely desired to call SCE-MI API functions from within the
signal handler, certainly they should be done inside try{}catch{}
blocks inside that signal handler.

Same with SystemC threads. The call root of any thread should have
its own try{} catch{} block if it is to expected to call SCE-MI API
functions in any call chain below it, and it has been decided to
use exception throws inside the error handlers.

One slight clarification to what you stated above, you said
that "it is possible for an application to call the SCE-MI
error handler ...". Generally the application itself does
not call the error handler directly. Rather, the SCE-MI infrastructure
does when it detects an exception. However, for purposes of
the rest of your points above, it does not matter who calls it,
you still have to solve the issue of what call chain it is in.

>
> If we want to maintain that it should be allowed for the user
> to throw C++ exceptions in the SCE-MI error handler, then in the
> example above, the implementation must somehow stash the error
> information away and get back to a place where the error handler
> can be called and throw the exception safely.

johnS:
Or stash away a flag that indicates a SCE-MI API function needs
to be called as I suggested above.

>
> Ok, I am not suggesting to remove C++ exception handlingr as a
> valid error reporting mechanism, I just wanted to point out some
> less obvious consequences of this.
>
> Per
>

-- johnS

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 Jun 23 05:39:33 2004