Failboxes: Provably Safe Exception Handling
The primary goal of exception mechanisms is to help ensure that when an operation fails, code that depends on the operation’s successful completion is not executed (a property we call dependency safety). However, the exception mechanisms of current mainstream programming languages make it hard to achieve dependency safety, in particular when objects manipulated inside a try block outlive the try block.
Many programming languages, mechanisms and paradigms have been proposed that address this issue. However, they all depart significantly from current practice. In this paper, we propose a language mechanism called failboxes. When applied correctly, failboxes have no significant impact on the structure, the semantics, or the performance of the program, other than to eliminate the executions that violate dependency safety.
Specifically, programmers may create failboxes dynamically and execute blocks of code in them. Once any such block fails, all subsequent attempts to execute code in the failbox will fail. To achieve dependency safety, programmers simply need to ensure that if an operation B depends on an operation A, then A and B are executed in the same failbox. Furthermore, failboxes help fix the unsafe interaction between locks and exceptions and they enable safe cancellation and robust resource cleanup. Finally, the Fail Fast mechanism prevents liveness issues when a thread is waiting on a failed thread.
We give a formal syntax and semantics of the new constructs, and prove dependency safety. Furthermore, to show that the new constructs are easy to reason about, we propose proof rules in separation logic. The theory has been machine-checked.
KeywordsVirtual Machine Exception Handling Java Virtual Machine Database Object Proof Rule
Unable to display preview. Download preview PDF.
- 1.Armstrong, J.: Making reliable distributed systems in the presence of software errors. PhD thesis, Royal Institute of Technology, Stockholm, Sweden (2003)Google Scholar
- 4.Dony, C.: Exception handling and object-oriented programming: a synthesis. In: Proc. OOPSLA (1990)Google Scholar
- 5.Fetzer, C., Högstedt, K., Felber, P.: Automatic detection and masking of non-atomic exception handling. In: Proc. Intl. Conf. Dependable Systems and Networks (DSN) (2003)Google Scholar
- 6.Flanagan, C., Leino, K.R.M., Lillibridge, M., Nelson, G., Saxe, J.B., Stata, R.: Extended static checking for Java. In: Proc. PLDI, pp. 234–245 (2002)Google Scholar
- 7.Flatt, M., Findler, R.B.: Kill-safe synchronization abstractions. In: Proc. PLDI (2004)Google Scholar
- 8.Flatt, M., Findler, R.B., Krishnamurthi, S., Felleisen, M.: Programming languages as operating systems (or Revenge of the son of the Lisp machine). In: Proc. Intl. Conf. on Functional Programming (ICFP) (1999)Google Scholar
- 11.Hawblitzel, C., von Eicken, T.: Luna: a flexible Java protection system. In: Proc. OSDI (2002)Google Scholar
- 12.Jacobs, B., Piessens, F.: Failboxes: Prototype implementations, prototype verifier, machine-checked metatheory (July 2008), http://www.cs.kuleuven.be/~bartj/failboxes
- 13.Jacobs, B., Müller, P., Piessens, F.: Sound reasoning about unchecked exceptions. In: Proc. ICFEM (2007)Google Scholar
- 16.Marlow, S., Jones, S.P., Moran, A., Reppy, J.: Asynchronous exceptions in Haskell. In: Proc. PLDI (2001)Google Scholar
- 18.Rudys, A., Clements, J., Wallach, D.S.: Termination in language-based systems. In: Network and Distributed System Security Symposium (NDSS) (February 2001)Google Scholar
- 19.Shavit, N., Touitou, D.: Software transactional memory. In: Proc. PODC, pp. 204–213 (1995)Google Scholar
- 20.Shore, J.: Fail fast. IEEE Software (September 2004)Google Scholar
- 21.Toub, S.: Keep your code running with the reliability features of the.NET Framework. MSDN Magazine (October 2005)Google Scholar
- 22.Weimer, W., Necula, G.C.: Finding and preventing run-time error handling mistakes. In: Proc. OOPSLA, pp. 419–431 (October 2004)Google Scholar