1. Csontos Péter, Porkoláb Zoltán Eötvös Loránd Tudományegyetem, Budapest ECOOP 2001 On the complexity of exception handling

2. 2 On the complexity of exception-handling Outline  Background of software metrics  Basics of the proposed complexity measure  Advanced issues and proposed solutions

3. 3 On the complexity of exception-handling Software complexity measures  Static complexity –Not algorithmic (run-time) complexity –Not function points –Based only on the source code of the program  Usage of software metrics –Measuring software quality –Estimating software development projects –Comparing frameworks, component libraries or other architectures –Test plan creation

4. 4 On the complexity of exception-handling Reasons of mesuring exception handling  Widespread usage in object-oriented programs –It cannot be avoided when dealing with OO programming –Not a separate complexity measure, just an integrated part of the basic metrics  Different behaviour in different programming languages  Non-structural nature – in some cases increases the complexity of the program  Relatively few research has been there in this area

5. 5 On the complexity of exception-handling Outline  Background of software metrics  Basics of the proposed complexity measure  Advanced issues and proposed solutions

6. 6 On the complexity of exception-handling Evolution of the particular complexity measure used  McCabe, 1976: Cyclomatic number (call-flow graphs and predicate count)  Harrison and Magel, 1981, Piwowarski, 1982: Nested level (two ifs, one nested into the other are more complex, than two sequential ifs, etc.)  Fóthi and Nyéky-Gaizler, 1993: Handling of data (much closer to the exact size of the program)  Porkoláb, 1999: Object-orientation (abstract data types and inheritance)  Csontos and Porkoláb, 2001: Exceptions, language issues

7. 7 On the complexity of exception-handling Process of using the complexity measure Parsing the source code Sum up the complexity Create call- flow graph Determine nesting level Source code Syntax tree Call-flow graph Call flow graph with nodes labeled with nesting level Complexity of the program

8. 8 On the complexity of exception-handling Details on usage of our metrics  The call-flow graph of the program is created –Predicates and data handling (read and write instructions: assignment, function parameters) –Throwing of an exception is also handled as a predicate node  Determining nesting level –The predicates (if, while, etc.) determine the nesting level of an instruction –The greater nesting level, the greater complexity  The data, as well as the predicates are added to the measure

9. 9 On the complexity of exception-handling Outline  Background of software metrics  Basics of the proposed complexity measure  Advanced issues and proposed solutions

10. 10 On the complexity of exception-handling Language- and compiler- dependent call-flow graphs  Different languages: different semantics (call-flow graphs) for the same syntactic construct  C++: Weakly defined semantics in several cases  Implicit behaviour of programs can differ among different compilers or different modes of the same compiler (e.g. optimized or not)  Example: a[i++]=f();  Complexity measure: the maximum value of the possible execution paths  It is needed to enumerate such cases (non-trivial, requires further research)

11. 11 On the complexity of exception-handling Possible call-flow graphs of the example statement a[i++]=f(); // f() throws an exception ++f()ex i a[i]f ret =++f()ex i a[i]f ret =

12. 12 On the complexity of exception-handling Freeing resources  Allocation of resources in a try block before hazardous function calls: can be handled different ways  Java: finally construct  C++: no finally construct, but several approaches exist to solve the issue: –catch(…) construct: the program is a bit more complicated and the complexity is greater (plus one function call and one explicit throw forwarding) –Separate Resource class with the allocation in the constructor and freeing in the destructor: complexity is smaller if the resource is heavily used

13. 13 On the complexity of exception-handling Uncaught exceptions and Class libraries  Proprietary libraries, API’s: the source code is not published  Just the interface is available  Measuring complexity of exception handling: the internal implementation of a called function has relevance because of the implicit behaviour  Solution: every theoretically possible exception handling path has to be measured and the complexities summed up  Java: trivial, throws clause is mandatory  C++: non-trivial, throws clause is not mandatory –Not algorithmic (run- time) complexity –The unexpected() function is called implicitly –The complexity is greater (because of the plus function call)

14. 14 On the complexity of exception-handling Future directions  Measuring UML models  Comparing with function point metrics –Joint project of ELTE and IQSOFT –Measuring completed projects –Trying to use this measure for project estimation  Applying other ortogonal paradigms –Aspect-oriented programming –Generic programming –Functional programming  More language parsers for the tool –Java parser and automatic measurement tool is being completed –C++, Eiffel, Ada, etc. parsers will be added

15. 15 On the complexity of exception-handling Questions ?