Error Handling: From Theory to Practice
description
Transcript of Error Handling: From Theory to Practice
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