Robust Exception Handling in an Asynchronous Environment

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
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 gt Asynchronous
gt Wait-by-necessity gt
3
Incompatibilities with exceptions
Introduction - Problem - Main Approaches - Our
Proposal - Conclusion

• 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
Main Existing Approaches
Introduction - Problem - Main Approaches - Our
Proposal - Conclusion
Solution Example Benefits Drawbacks
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
5
Our Proposal Barriers
Introduction - Problem - Main Approaches - Our
Proposal - Conclusion

• 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
Main API
Introduction - Problem - Main Approaches - Our
Proposal - Conclusion

• tryWithCatch
• Pushes the exception mask

// foo1 and foo2 may // throw exceptions tryWithCa
tch(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

7
Entry Barrier
Introduction - Problem - Main Approaches - Our
Proposal - Conclusion

• 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
Asynchronism Consequences
Introduction - Problem - Main Approaches - Our
Proposal - Conclusion

• 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
Stacks inconsistencies
Introduction - Problem - Main Approaches - Our
Proposal - Conclusion
// foo1 and foo2 may // throw exceptions tryWithCa
tch(AnException.class) try res1
ao1.foo1(param1) res2 ao2.foo2(param2)
endTryWithCatch() catch (AnException e)
// Error handling finally
removeTryWithCatch()
Ex.class
Ex.class
Java stack
Emulated stack

• No information as to when an exception is thrown
• The emulated stack is corrupt
• Fix in the finally block

10
Conclusion
Introduction - Problem - Main Approaches - Our
Proposal - 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