On Sep 20, 2010, at 07:32 , Peter Soetens wrote:

> On Monday 20 September 2010 11:28:15 Markus Klotzbuecher wrote:
>> On Mon, Sep 20, 2010 at 11:16:53AM +0200, Peter Soetens wrote:
>>> On Monday 20 September 2010 08:44:00 Markus Klotzbuecher wrote:
>>>> Dear List,
>>>>
>>>> I'm trying to figure out which parts of the RTT API might throw
>>>> exceptions. I recall that calling a methods might throw (how about
>>>> sending?) but where else?
>>>
>>> Sending or calling operations will throw if there's nothing connected to
>>> them. It's one of these places where we can't return 'false' because the
>>> operation's signature dicates the return type. This case is still under
>>> documented / under specified. You need to catch(...) in order to catch
>>> them all, later RTT versions will specify the exception type to catch.
>>>
>>> The operation factory functions throw of course, in order to deliver a
>>> correct error message. These are well documented.
>>
>> Ok, thanks! AFAIK for I can avoid all of these by some checking,
>> e.g. only calling if the OperationCaller is ready().
>
> But that's a race in case of inter-process communication. It might die between
> ready() and call()/send().

+1

>>> Other code does not throw because we wanted to be able to compile 'low
>>> level code' with -fno-exceptions. The problem here is that
>>> boost::shared_ptr did not allow this at a certain point, so I gave up
>>> maintaining/checking this.
>>>
>>> All exceptions should be documented in the Doxygen API docs.
>>
>> Ok!
>>
>> Wasn't there also the case that CORBA (TAO only??) throws a timeout
>> exception if the network goes down? Or is this one caught before
>> reaching the user?
>
> No middleware exceptions may be leaked, so it's supposed to be caught by RTT.

COBRA can definitely throw exceptions that RTT doesn't catch. The ones that I am thinking of are related to startup and connection disruption though.
S

On Mon, 20 Sep 2010, Peter Soetens wrote:

> On Monday 20 September 2010 11:28:15 Markus Klotzbuecher wrote:
>> On Mon, Sep 20, 2010 at 11:16:53AM +0200, Peter Soetens wrote:
>>> On Monday 20 September 2010 08:44:00 Markus Klotzbuecher wrote:
>>>> Dear List,
>>>>
>>>> I'm trying to figure out which parts of the RTT API might throw
>>>> exceptions. I recall that calling a methods might throw (how about
>>>> sending?) but where else?
>>>
>>> Sending or calling operations will throw if there's nothing connected to
>>> them. It's one of these places where we can't return 'false' because the
>>> operation's signature dicates the return type. This case is still under
>>> documented / under specified. You need to catch(...) in order to catch
>>> them all, later RTT versions will specify the exception type to catch.
>>>
>>> The operation factory functions throw of course, in order to deliver a
>>> correct error message. These are well documented.
>>
>> Ok, thanks! AFAIK for I can avoid all of these by some checking,
>> e.g. only calling if the OperationCaller is ready().
>
> But that's a race in case of inter-process communication. It might die between
> ready() and call()/send().

And that's exactly where Markus' research on "distributed FSM" should
provide a "best practice" solution :-)

>>> Other code does not throw because we wanted to be able to compile 'low
>>> level code' with -fno-exceptions. The problem here is that
>>> boost::shared_ptr did not allow this at a certain point, so I gave up
>>> maintaining/checking this.
>>>
>>> All exceptions should be documented in the Doxygen API docs.
>>
>> Ok!
>>
>> Wasn't there also the case that CORBA (TAO only??) throws a timeout
>> exception if the network goes down? Or is this one caught before
>> reaching the user?
>
> No middleware exceptions may be leaked, so it's supposed to be caught by RTT.

It is not completely clear to me what the definition of "middleware
exceptions" is, but the Communication between components has a distributed
responsibility:
- the Computation going on in a component should not have to know about
these things, but it should be ready (read: "sufficiently robust") to
work with "middelware data" that is provided to it (_synchronously_, from
its local container!) that is created by other components (in other
containers, typically) at any possible time.
- the Communication component should have a similar robust behaviour, but
typically _asynchronously_.

What should happen exactly when something goes wrong (i.e., an "exception"
occurs) with the Communication is not so clear to me, yet. And the reason
is that so many different things can go wrong in many different places.

We should take a good look at the "high availability" middleware frameworks
to see whether they have some "best practices" to learn from...

Herman

On Mon, Sep 20, 2010 at 01:32:10PM +0200, Peter Soetens wrote:
> On Monday 20 September 2010 11:28:15 Markus Klotzbuecher wrote:
> > On Mon, Sep 20, 2010 at 11:16:53AM +0200, Peter Soetens wrote:
> > > On Monday 20 September 2010 08:44:00 Markus Klotzbuecher wrote:
> > > > Dear List,
> > > >
> > > > I'm trying to figure out which parts of the RTT API might throw
> > > > exceptions. I recall that calling a methods might throw (how about
> > > > sending?) but where else?
> > >
> > > Sending or calling operations will throw if there's nothing connected to
> > > them. It's one of these places where we can't return 'false' because the
> > > operation's signature dicates the return type. This case is still under
> > > documented / under specified. You need to catch(...) in order to catch
> > > them all, later RTT versions will specify the exception type to catch.
> > >
> > > The operation factory functions throw of course, in order to deliver a
> > > correct error message. These are well documented.
> >
> > Ok, thanks! AFAIK for I can avoid all of these by some checking,
> > e.g. only calling if the OperationCaller is ready().
>
> But that's a race in case of inter-process communication. It might die between
> ready() and call()/send().

Right. I'll catch them.

> >
> > > Other code does not throw because we wanted to be able to compile 'low
> > > level code' with -fno-exceptions. The problem here is that
> > > boost::shared_ptr did not allow this at a certain point, so I gave up
> > > maintaining/checking this.
> > >
> > > All exceptions should be documented in the Doxygen API docs.
> >
> > Ok!
> >
> > Wasn't there also the case that CORBA (TAO only??) throws a timeout
> > exception if the network goes down? Or is this one caught before
> > reaching the user?
>
> No middleware exceptions may be leaked, so it's supposed to be caught by RTT.

Perfect.

Thanks
Markus