Error Handling:
From Theory to Practice
Ivan Lanese
Computer Science Department
University of Bologna/INRIA
Italy
Joint work with Fabrizio Montesi
italianaSoftware s.r.l./IT University of Copenhagen
1
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, looselycoupled 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 to
deal 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 nonencodability 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 fullfledged 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