1

Ivan LaneseComputer Science Department

University of Bologna/INRIAItaly

Error Handling: From Theory to Practice

Joint work with Fabrizio MontesiitalianaSoftware s.r.l./IT University of Copenhagen

Roadmap

The quest for error handling primitives

Theoretical concerns Practical concerns Conclusive remarks

Roadmap

The quest for error handling primitives

Theoretical concerns Practical concerns Conclusive remarks

Our aim

Error handling is a fundamental aspect of calculi and languages for service-oriented computing systems

Many approaches, no one accepted as the “best” one Which properties make an approach good? Are those properties the same in theoretical calculi and

full-fledged languages?

Service Oriented Computing (SOC)

SOC is a paradigm to program distributed applications– Based on the composition of dynamically discovered, loosely-

coupled services– Services interact using the one-way and request-response

patterns Has to deal with interoperability, dynamicity,

reconfiguration… Based on standards for data (XML), communication

(SOAP), discovery (WSDL and UDDI) and orchestration (BPEL)

Allows integration of services from different companies

Error handling

Safe composition of services requires todeal with faults– Scarce guarentees on service behaviour

because of loose coupling– Unexpected events can happen

Faults should be managed so that the whole system can reach a consistent state

Tackled using long-running transactions and compensations

Error handling in everydays life

A process

Parameters:

Fault handler:

Some terminology (in the BPEL/Jolie style)

Long-running transaction: transaction that performs approximate rollback in case of error

Handler: piece of code executed for error recovery– Q in the Java code try P catch e Q

Scope: a boundary for handler execution– Scopes may be nested

Fault handler: handler executed in case of internal fault Termination handler: handler that smoothly terminates

an activity in case of an external fault Compensation: handler for undoing the effects of an

activity in case of later fault

Process calculi

The complexity of error handling requires formal models– To really understand the behavior of systems– To prove properties

Process calculi are a widely used model of concurrency– In particular for SOC and error handling

Good basis for developing a real language– Allows to experiment and assess different primitives– λ-calculus is the basis of functional languages– Many languages based on π-calculus

» E.g., Pict

The zoo of calculi for error handling

CSP interrupt operator (Hoare, 1985) Πt-calculus (Bocchi, Laneve, Zavattaro, 2003) StAC (Butler, Ferreira, 2004) cJoin (Bruni, Melgratti, Montanari, 2004) cCSP (Butler, Hoare, Ferreira, 2004) SAGAs calculi (Bruni, Melgratti, Montanari, 2005) Webπ (Laneve, Zavattaro, 2005) COWS (Lapadula, Pugliese, Tiezzi, 2007) SOCK (Guidi, Lanese, Montesi, Zavattaro, 2008) Dcπ (Vaz, Ferreira, Ravara, 2008) ATc (Bocchi, Tuosto, 2010)

Roadmap

The quest for error handling primitives

Theoretical concerns Practical concerns Conclusive remarks

Desirable properties for calculi

There are too many calculi Which are the aims those calculi want to achieve? Which are the interesting dimensions for comparing

them? We consider 4 interesting properties

– Full specification– Expressiveness– Intuitiveness– Minimality

Apply to calculi in general, but we concentrate on error handling

Full specification

The calculus has to specify the behavior of error handling in all possible cases

Including boundary/rare cases– E.g., what happens if a fault handler throws a fault?– E.g., what happens if a fault happens in parallel to a running

request-response service invocation? Usually, all theoretical models enjoy this property

– Easy to check for instance for semantics defined by structural induction

This is not the case for informal specifications– BPEL specification is unclear on many points– Different BPEL implementations have different behaviors

Expressiveness

The available primitives should be able to express all the policies that may be needed for programming applications

Difficult to define which are “all the policies” Normally tackled using encodings and case studies An encoding of a calculus C1 into C2 proves that C2 is at

least as expressive as C1– Which properties should the encoding preserve?

Gaps in expressiveness can be proved via non-encodability results

A case study shows the suitability of a calculus for a particular application

Intuitiveness

The behavior of the primitives should match the intuition of the programmer– (after some training)

Having the calculus following some clear and orthogonal principles strongly helps– E.g., a scope may either fail by throwing a unique fault, or succeed by

installing its compensation for later use Those principles should be defined before formalizing the

calculus Those principles are the base of the manual for the programmer

– For complex cases it may be necessary to go back to the specification It is possible to prove that the calculus semantics really follows

those principles

Minimality

The calculus should avoid redundant or overlapping primitives– More easy to understand– More easy to prove properties

Having the calculus following some clear and orthogonal principles strongly helps (again!)

One may prove that the calculus is more expressive than its fragments– Difficult result

Roadmap

The quest for error handling primitives

Theoretical concerns Practical concerns Conclusive remarks

From a calculus to a language

Calculi can (should?) be used as a basis for implementing languages– Many examples starting from λ-calculus and π-calculus– Not many examples for error handling in SOC

Which is the difference between a calculus and a full-fledged language?– No easy answer– Languages are used for programming real applications– Personal (not so serious) answer: languages allows comments

Languages should have “something more”

Desirable properties for languages

The differences between calculi and languages influence the properties seen before– Minimality less strict, intuitiveness even more important

We devise 3 new properties– Usability– Robustness– Compatibility

Again, we concentrate on error handling Based on the Jolie experience

– A language for programming SOC applications based on the calculus SOCK

– With strong support for error handling

Usability

The programmer should be able to use the language for its day-by-day programming– Includes expressiveness and intuitiveness

Powerful data handling is needed– Normally not detailed in calculi

The most common patterns should be easy and fast to program

Usability in Jolie

SOCK throw primitive has the syntax throw(f) This becomes throw(f,M) in Jolie

– M is some data to be used during error recovery– E.g., information on the fault or an error message– Can be accessed by the handlers

More interesting (but complex!) examples in the paper

Robustness

The language should be able to deal with failures in the environment– Network problems, node crashes

Those aspects normally not modelled in calculi– Unless they are dedicated calculi

Programming languages need to manage these E.g., if a communication chennel breaks a system fault

has to be thrown Jolie runtime support raises a system fault IOexception

This can be managed using the standard SOCK/Jolie handler constructs

Compatibility

Real programs have to interact with different, heterogeneous applications

These applications may follow different protocols, in particular for error handling

SOCK/Jolie services ensure notification in case of remote errors– Useful for distributed error handling

Non Jolie services provide no such a guarentee Jolie engine checks when a connection is closed

unexpectedly and provides a notification via IOexception

Roadmap

The quest for error handling primitives

Theoretical concerns Practical concerns Conclusive remarks

Conclusions

Defining a good calculus for error handling in SOC is not easy– Important to follow clear principles

… but there are a lot of good proposals Defining a good language based on them is even more

difficult … and there are not many proposals around We have described some of the main issues and pointed

out possible approaches We hope to see new languages for SOC with formal

underpinning in the future

End of talk