One more comment ... 

Bojsen, Per wrote: 
> Hi, 
> 
> 
> 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 

johnS: 
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. 

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. 

> use model? In that case, the standard should be modified to explicitly 
> state so as this has implementation consequences. 
> 
> Thanks, 
> 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