Re: No exceptions!

Notice also that exceptions cause (limited) performance degradation. 
More important is the fact that they cannot pass "thread boundaries". 
They might in fact go up all the way to the thread entry, but not any 
further. If I am not mistaking, behavior is undetermined (and might 
even cause problems to the scheduler) if they have not been handled 
(catched) at that moment.

Return codes, which are simple data can be passed between threads 
without problems.

Bob

On 2002.03.05 11:58 Peter Soetens wrote:
> On Tuesday 05 March 2002 00:01, you wrote:
> > Hi.
> > I guess we cannot use exceptions in the API:s and object definitions
> since
> > the realtime parts cannot handle it?
> > (At least that was one of the things I picked up from Peters seminar
> here
> > at KTH last Thursday.)
> 
> this fact can be hidden for the API user.  STL provides this by
> defining
> __throw(), __try(),... macros which are wrapers to the real try throw
> catch
> methods or to empty function calls when STL_NO_EXCEPTIONS is defined.
> 
> I'm not sure how this must be done with the IDL discription (we can
> talk
> about that next week :-) ).
> 
> >
> > This means we normally have to use the return values for status
> information
> > instead of returning more "useful" stuff;-(
> 
> returning status information (which is indeed bad programming practice
> if you
> got exceptions at hand) is only required for the components that must
> be able
> to run in the realtime part. I'd also prefer to signal "exceptions"
> through
> event mechanisms (this is on my TODO list).
> 
> Peter
> 
> >
> > ./Anders
> 
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
>