Re: [Bug 1044] New: Broken error propogation logic within solvers

On Wed, 9 Oct 2013, Sylvain Joyeux wrote:

> On 10/09/2013 08:32 AM, Herman Bruyninckx wrote:
>> The
>> traditional API-based approach has problems with letting _all_ the
>> monitoring information be accessible in the whole application, _because_
>> one wants to communicate all that information through the method call
>> signature.
> Eh. Not since modern programming languages got there. You know, more
> than 20 years ago. Sell your 'component-functional-block-oriented'
> approach more because of the schedulability / control than monitoring.

Agreed! The monitoring problem is indeed rather caused by a lack in the
education, not the technology.

> Pure monitoring (i.e. status, internal monitoring measures) are usually
> passed through dedicated method calls (since they don't have to
> interrupt the control flow). This obviously hits the problem of
> interpretation: if solver X has a given reporting structure and Y
> another, you don't get a 'common' monitoring capability, and inheritance
> can be used to provide common generic monitoring information without
> losing the more detailed one.
>
> Errors are passed through exceptions, which is allows for error
> classification, inheritance and enrichment. The inheritance here, again,
> allows for generic code to interpret part of the errors it can interpret
> without loss of information.

Herman
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev