R obust E xception H andling in an A synchronous E nvironment

1. Robust Exception Handling in an Asynchronous Environment • Introduction • Problem • Main Approaches • Our Proposal • Conclusion Denis Caromel, Guillaume Chazarain OASIS Research group, INRIA INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis

2. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Context: ProActive • Free (LGPL) Java library for distributed computing • Asynchronous method calls on active objects • Method calls like RMI/RPC • Execution goes on • Returnsa Future object, placeholder for the result • Transparent wait-by-necessity upon access Asynchronous => Asynchronous => Wait-by-necessity => res1 = ao1.foo1(...); res2 = ao2.foo2(...); res = res1.bar(...);

3. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Incompatibilities with exceptions • Exceptions are tied to synchronism • Based on stack unwinding • With asynchronism, the stack state cannot be relied upon // foo1 and foo2 may // throw exceptions try { res1 = ao1.foo1(param1); res2 = ao2.foo2(param2); } catch (AnException e) { // Error handling } res = res1.foo(res2); • Previous solution: synchronously handle every call that could throw an exception • Our contribution: maintain asynchronism even with exceptions

4. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Main Existing Approaches

5. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Our Proposal: Barriers • Exception in the future with a barrier at the end of the block • The exception is thrown upon access to the future • Before leaving the block, we wait for every associated call to return • Calls with compatible exception types • Guarantee that the exception is thrown in the right block

6. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Main API • endTryWithCatch • Waits for the calls • Pops the exception mask • removeTryWithCatch • Fixes the stack • tryWithCatch • Pushes the exception mask // foo1 and foo2 may // throw exceptions tryWithCatch(AnException.class); try { res1 = ao1.foo1(param1); res2 = ao2.foo2(param2); endTryWithCatch(); } catch (AnException e) { // Error handling } finally { removeTryWithCatch(); } res = res1.foo(res2);

7. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Entry Barrier • Nested blocks class MyException extends Exception {} try { A a = ro.foo(); // throws MyException /* Barrier here */ try { a.bar(); // throws MyException } catch (MyException e) { // a.bar() error handling // Without the barrier, the ro.foo() // exception would be handled here } } catch (MyException e) { // ro.foo() error handling } • The exception will be handled in the surrounding block, not the nested one

8. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Asynchronism: Consequences • Illegal consecutive calls • Throw the exception as soon as possible? • No: unpredictable behaviour We rely on the wait-by-necessity // foo1 and foo2 may // throw exceptions try { res1 = ao1.foo1(param1); res2 = ao2.foo2(param2); } catch (AnException e) { // Error handling } res = res1.foo(res2); • Consecutives exceptions • With synchronism: only the first one We only keep the first one

9. Introduction - Problem - Main Approaches - Our Proposal - Conclusion AnException Stacks inconsistencies // foo1 and foo2 may // throw exceptions tryWithCatch(AnException.class); try { res1 = ao1.foo1(param1); res2 = ao2.foo2(param2); endTryWithCatch(); } catch (AnException e) { // Error handling } finally { removeTryWithCatch(); } • No information as to when an exception is thrown • The emulated stack is corrupt • Fix in the finally block Ex.class Ex.class Java stack Emulated stack

10. Introduction - Problem - Main Approaches - Our Proposal - Conclusion Conclusion • Existing mechanisms too limited • Asynchronous calls with exceptions • Looses some asynchronism • In practice the synchronism comes from the wait-by-necessity, not the barrier • Other techniques are being considered • Checkpointing to cancel illegal calls