Blame Analysis for Components Matthias Felleisen Rice University with Matthew Flatt (Utah) and Robby Findler (Rice)

Components and Errors Package Server: public class A { … public void method1(A a) { … } } public class B extends A { // method1 can only process B’s B b = (B)a; Package Client: class C { A anA = A( … ) ; B a_B = B( … ) ; … a_B.method1(anA); .. anA = a_B; ... } … it ends up raising a exception! This system type-checks but …

Who’s to blame? The designer of A and B were forced to type method1 as A -> void by Java’s type system The designer of B knows perfectly well that method1 can only work with arguments of type B -- but can only publish this restriction as an informal comment that the compiler can’t type-check (plus a run-time check inside of his code).

Contracts … We need contracts between components. (That’s an old idea.) Our contracts help us overcome weaknesses in existing type systems. For example, a contract can specify assertions like “the A input to method1 must always be a B”. Even such simple contracts require reasoning about “higher-order” data. (See very last slide)

… and Blame We need a mechanism for “enforcing” contracts with theorem-proving and/or run-time mechanisms so that we can assign blame. This requires a “blame transformation” --- a code transformation that distributes checks and issues proper error messages. Blame should take one of two forms: A component does not satisfy its “export” contract. A component violates its “import” contracts.

Components, Contracts, and Errors Package Server: public class A { … public void method1(A a) { … } } public class B extends A { B b = (B)a; Package Client: class C { A anA = A( … ) ; B a_B = B( … ) ; … a_B.method1 (… (B)anA … ) ... anA = a_B; …. } interface B { void method1(A a) “a must be a B”; … } The contract enables us to insert “contract code” into Client to make sure method1 receives only B’s.

Composing Components with Contracts No static type system is strong enough to specify all contractual assertions between components. Our example is simplistic but illustrates a point. We need to develop languages in which we specify easily computable assertions, and mechanisms for assigning blame in clients and servers. In addition, we need proof assistants to eliminate such code, where possible, and to warn programmers where failures may occur (relative to the proof system).

Higher-Order Problems (“Objects are Multi-Entry Closures”) Package Server: public class A { … public void method1(A a) { … } } public class B extends A { B b = (B)a; Package Client1; public class D { A anA = A( … ) ; B a_B = B( … ) ; public void method3() { ... a_b.method1 (… (B)anA … ) ... anA = a_B; } } Package Client2; class C { ... void method4(D d) { … d.method3(); } Object d is passed in, call to method3 triggers exception