Practical Exception Specifications

1. Practical Exception Specifications ECOOP Workshop Exception Handling in Object Oriented Systems Donna Malayeri and Jonathan Aldrich

2. Exceptions: a double-edged sword? • Useful for writing error-handling code • allows localizing handler code • harder to ignore error conditions • But can produce confusing control flow • Have been compared to GOTO

3. Are tools the answer? • Most require whole-program analysis, and are not scalable • Don’t allow specifying and enforcing a policy • bad for team development

4. Are exception specifications the answer? • Not current specification systems: • too heavyweight • too fine-grain • difficult to maintain • little or no help for understanding exception flow

5. Error: unhandled exception SQLException setValue(Object val) setValue(key, val) theDB.save(key, value);

6. Error: unhandled exception SQLException Error: unhandled exception SQLException setKey(String key, Object val) setValue(Object val) throws SQLException setValue(key, val) throws SQLException theDB.save(key, value);

7. publicsetKey(String key, Object val) throws SQLException throws SQLException Problem! Programmer didn’t realize that UserPrefs is supposed to hide storage details setValue(Object val) throws SQLException User Preferences abtraction is violated! setValue(key, val) throws SQLException theDB.save(key, value);

8. So, Java “throws” is not a solution • Not expressive • Not lightweight • Difficult to maintain • Easily become imprecise • No aid in comprehension of exception flow

9. In contrast, practical exception specifications should be: • Expressive • Lightweight • Easy to maintain • An aid for understanding exception flow and exception policies • ExnJava has all of these properties

10. ExnJava is more expressive Specify exception policies for Java packages Programmer adds specification: package util.userPrefs may only throw PreferenceException

11. ExnJava combines inference and annotations • Programmer writes throws declarations for public and protected methods only • Other declarations are inferred • Performs a per-package analysis • scalable • future work: modules instead of packages

12. ExnJava Error: Public methods in util.userPrefs may not throw SQLException inferred inferred Error: unhandled exception SQLException User Preferences Module • public{PrefKeys.getKey(key).setValue(val);} • publicsave() {Serializer.save();} class UserPrefs setKey(String key, Object val) • {Serializer.setValue(this, val);} class PrefKeys setValue(Object val) throws SQLException • static{cache.store(key, val);} class Serializer throws SQLException setValue(key, val) theDB.save(key, value);

13. ExnJava User Preferences Module class UserPrefs • publicsetKey(String key, Object val){try{PrefKeys.getKey(key).setValue(val);} catch (SQLException e) {throw new PreferenceException(e); } } • publicsave() {Serializer.save();}

14. ExnJava specifications are maintainable • Fewer declarations means • fewer declarations to maintain • fewer declarations that can become imprecise • ExnJava includes tools • fix imprecise declarations • propagate throws declarations

15. Demo

16. Related Work • Robillard & Murphy • Jex • Sinha et al • exception analysis • views for exception flow

17. Summary of ExnJava Properties • Lightweight annotations • combination of inference and user annotations • Expressive • supports package exception policies • Easy to maintain • fewer annotations • tools: Propagate Throws, Fix Imprecise • Aids understanding exception flow • detailed views