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

2. 2/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK Context: ProActive Introduction - Problem - Main Approaches - Our Proposal - Conclusion Free (LGPL) Java library for distributed computing Asynchronous method calls on active objects Method calls like RMI/RPC Execution goes on Returns a Future object, placeholder for the result Transparent wait-by-necessity upon access res1 = ao1.foo1(...); res2 = ao2.foo2(...); res = res1.bar(...); Asynchronous => Wait-by-necessity =>

3. 3/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK 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 Introduction - Problem - Main Approaches - Our Proposal - Conclusion

4. 4/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK Main Existing Approaches SolutionExampleBenefitsDrawbacks Callback (JR, NFE, Kava, ARMI) class MyExcHandler { void handle(Exc e){... } Easy Generic behaviour Incomplete context capture Unwinding impossible Limited continuation Exception in the future (Mandala/RAMI, Java 1.5, ARMI) try { future = asyncCall(); } catch (Exc e) { … } future.useIt(); Built upon a real exception handling mechanism Exceptions thrown in an unpredictable way, outside of the catch scope Introduction - Problem - Main Approaches - Our Proposal - Conclusion

5. 5/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK 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 Introduction - Problem - Main Approaches - Our Proposal - Conclusion

6. 6/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK Main API // 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); endTryWithCatch Waits for the calls Pops the exception mask removeTryWithCatch Fixes the stack tryWithCatch Pushes the exception mask Introduction - Problem - Main Approaches - Our Proposal - Conclusion

7. 7/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK Entry Barrier The exception will be handled in the surrounding block, not the nested one 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 } Nested blocks Introduction - Problem - Main Approaches - Our Proposal - Conclusion

8. 8/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK 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 Introduction - Problem - Main Approaches - Our Proposal - Conclusion

9. 9/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK Stacks inconsistencies Java stack Emulated stack No information as to when an exception is thrown The emulated stack is corrupt Fix in the finally block // 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(); } Ex.class AnException Introduction - Problem - Main Approaches - Our Proposal - Conclusion

10. 10/10 Denis Caromel, Guillaume Chazarain ECOOP 2005 Workshop on Exception Handling in Object-Oriented Systems - July 25, 2005 - Glasgow UK 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 Introduction - Problem - Main Approaches - Our Proposal - Conclusion