Download to read offline
![3[Cristian TSC]
Exceptions and exception handling have a
high impact.
[Yuan et al. OSDI 14]
Two-thirds of the
studied system crashes
were due to exceptions.
35% of catastrophic
failures are caused by 3
trivial exception
handling anti-patterns.](https://image.slidesharecdn.com/ehpwithflowanalysisv1noaudio-180407175204/85/IEEE-SCAM-2017-Revisiting-Exception-Handling-Practices-with-Exception-Flow-Analysis-3-320.jpg)
![4
[Nakshatri et al MSR 16]
[Kery et al MSR 16]
[Asaduzzaman et al MSR 16]
[B de Pádua and Shang ICPC 17]
Exception handling has suboptimal usage
and lacks documentation.
[Kechagia and Spinellis MSR 14]
Best practices are often
not followed and anti-
patterns are still
prevalent.
69% of crash related
methods had
undocumented
exceptions.](https://image.slidesharecdn.com/ehpwithflowanalysisv1noaudio-180407175204/85/IEEE-SCAM-2017-Revisiting-Exception-Handling-Practices-with-Exception-Flow-Analysis-4-320.jpg)
![5[Bonifacio et al SCAM 15]
Exception handling is complex and hard to
learn.
[Sinha et al ICSE 14]
“Educational issue is a
common reason for
avoiding the use of
exception handling.”
“Complex implicit
control flow is always
present and is generally
not adequately
exercised. ”](https://image.slidesharecdn.com/ehpwithflowanalysisv1noaudio-180407175204/85/IEEE-SCAM-2017-Revisiting-Exception-Handling-Practices-with-Exception-Flow-Analysis-5-320.jpg)
More Related Content
Similar to IEEE SCAM 2017 Revisiting Exception Handling Practices with Exception Flow Analysis
IEEE SCAM 2017 Revisiting Exception Handling Practices with Exception Flow Analysis
- 1. Revisiting Exception Handling Practiceswith Exception Flow Analysis Guilherme B. de Pádua 1 Weiyi Shang @Gui_Padua_io
- 2. 2 ActionScript, Ada, BlitzMax, C++,C#, COBOL, D, ECMAScript, Eiffel, Java, ML, Object Pascal (e.g. Delphi, Free Pascal, and the like), PowerBuilder, Objective-C, OCaml, PHP (as of version 5), PL/1, PL/SQL, Prolog, Python, REALbasic, Ruby, Scala, Seed7, Tcl, Visual Prolog and .NET. Exception handling is a common practice.
- 3. 3[Cristian TSC] Exceptions andexception handling have a high impact. [Yuan et al. OSDI 14] Two-thirds of the studied system crashes were due to exceptions. 35% of catastrophic failures are caused by 3 trivial exception handling anti-patterns.
- 4. 4 [Nakshatri et alMSR 16] [Kery et al MSR 16] [Asaduzzaman et al MSR 16] [B de Pádua and Shang ICPC 17] Exception handling has suboptimal usage and lacks documentation. [Kechagia and Spinellis MSR 14] Best practices are often not followed and anti- patterns are still prevalent. 69% of crash related methods had undocumented exceptions.
- 5. 5[Bonifacio et alSCAM 15] Exception handling is complex and hard to learn. [Sinha et al ICSE 14] “Educational issue is a common reason for avoiding the use of exception handling.” “Complex implicit control flow is always present and is generally not adequately exercised. ”
- 6. 6 Exception handling iswell studied. Exception handling improvements are proposed.
- 7. 7 Given fact: Bcan throw 2 exceptions. 1 is handled by the catch. 1 is propagated by the throws. Exception handling practices example in Java: handling and propagating.
- 8. 8 Exception handling practicesexample in Java: raising and documenting. IO Exception IO Exception Invalid Path Exception 1 is raised by the throw and documented in comments. External @Javadoc getPath throws: InvalidPathException 1 is documented at the external documentation.
- 9. 9 FLOW FLOW .NET Compiler Platform (Roslyn) EclipseJDT Core 2 automated tools AST Exception flow analysis. . . . Source code + Dependencies + Documentation . . . 1) Identify Handlers Catch blocks 2) Construct call graphs 3) Identify sources of exceptions D G F E B C I Z K D B G F E C
- 10. 10 10,190 handlers 16 projects Java andC# 77,741 flows 8,050 invoked methods Case study design: subject projects.
- 11. 11 Studied aspects ofexception flows. IO Exception Invalid Path Exception External @Javadoc getPath throws: InvalidPathException Quantity (1) Diversity (2) Sources (3) Strategy and Actions (4)
- 12. Quantity (1): Potentiallyrecoverable yet propagated exceptions. 12 A D B F E C Potentially Recoverable Potentially Unrecoverable • Increased risk • Unnecessary complexity A B Handled: Invalid Path Exception Propagated: IO Exception 1) How many flows are potentially recoverable but yet propagated?
- 13. Quantity of possibleexceptions per try block. 13 1) A considerable amount of potentially recoverable exceptions are propagated. Language / Project C# Java SharpDe.. H. HDFS 0 5 10 15 20 #Prop.andPotentiallyRecoverab.. Median: 0 Median: 0 Exception flow analysis can provide automated tooling support to alert developers about not handling potentially recoverable exceptions.
- 14. Diversity (2): Thereare many different possible exception types. 14 • 136 C# types • 501 Java types A large number of exception types may show a “greater concern” with exception handling … but might be a burden to developers. 2) Does all exception flow types have the same prevalence in try blocks?
- 15. 2) Many possibleexception types appear in only one try block. 15 Up to 73% and 41% for two or less try blocks Up to 80% and 57% for three or less try blocks. Up to 57% for C# and 28% for Java of the exception types appear in only one try block. Developers may not need to be aware of all exception types in a project by receiving automated suggestions of the exceptions that he/she needs to understand.
- 16. Sources (3A): Therecould be multiple sources of a same exception. 16 IO Exception Invalid Path Exception Distinct methods per try block Lang Median Max Java 1 35 C# 1 19 A C B C • ⬆ Complexity • ⬆ Uncertainty • Affects developers and testers 3A) Does the multiple invoked methods can reveal the same possible exceptions?
- 17. 3A) Many possibleexceptions are traced from different methods. 17 More than 22% for C# and Java of the exception types are traced from 2 or more methods. Automated tools are needed to understand if a possible exception is traced back to different methods.
- 18. 18 Sources (3B): Sourcesof exception documentation. IO Exception Invalid Path Exception IO Exception External @Javadoc getPath throws: InvalidPathException Throw statement Documentation in commentsExternal documentation Method declaration 3B) Can automated flow analysis provide the documentation of possible exceptions?
- 19. Quantity of identifiedpossible exceptions per source of information. 19 3B) External documentation can reveal most of the possible exceptions. C# Java 93%71% Developers should leverage automated analyses that includes external documentation to understand possible exceptions.
- 20. 20 Strategy and Actions(4): Many handling actions can be identified. 12 actions automatically detected C# ≠ Java 4) What are the typical handling actions and their differences for C# and Java?
- 21. Values by Project.Differences are significant based on Wilcoxon Rank Sum test (p-value <0.05). 21 4) Java and C# have differences in various actions when handling exceptions. More in-depth analysis and user studies are needed to further understand the rationale of differences of Java and C# exception handling practices.
- 22.
Editor's Notes
- #3 All these programming languages have implemented exception handling features.
- #4 … And such features have a high impact …
- #5 … nevertheless, although it has impact, it still has suboptimal usage. Best practices were proposed, but are not followed. Our previous work on anti-patterns showed that they are still prevalent. Maybe developers are overwhelmed, let it slip through. One example is documentation, multiple studies touched that, here is a sample in which … slide 4: You need a wording connection between the left part and the right part.
- #6 … potential reasons for such issues could be the complexity and educational problems. A survey from scam 2015 revealed, among others, that education is a common reason to avoid EH. One consequence of EH that makes it harder to deal with is the fact that it changes the control flow. This ICSE paper points that out, mentioning that its always present and generally not adequately exercised. slide 5: the hinder modular reasoning thing and the complex implicit control flow, you need some layman wording in verbal to explain. Currenlty, people won't catch it. Highlight Educational Issue, make it looks like image. Use quotes, since they are. Switch the title. order
- #7 slide6: "understanding" and then improvements.
- #8 Summary: Try: attempted actions Catch or handler: handled exception handler actions
- #9 So, in our example, we know that B can throw two possible exceptions. But what if we didn’t know? Where that information could be found? If we have the source code, we can read the declaration of B. There we find two methods, C and getPath. We can then read the declaration of C. In C we find a throw statement. That is a newly raise exception. We also find a throws blocks, that propagates the exception. Moreover, the same exception is also documented as a comment in the source code.
- #10 To abstract the example, let’s use a simple call graph, in which a calls b. In the case of polymorphism and ambiguity, the call graph is approximated. Explain: abstract a and b
- #11 # of exception types: 637 # of invoked methods: 8 050 # of declared methods: 6 819
- #12 Quantity Diversity Sources Met and Doc Hand Strat and Actions
- #13 So in our example have 1 handled, 1 propagated. According to C# and Java specification, the exceptions could be potentially recoverable or not. For example, developers are not expected to recover from OutOfMemoryException, nevertheless, they should be able to recover from FileNotFoundException
- #14 … So we measure this by looking at the number of exceptions per try block. In this plot, each dot is a try block of a given project. We have here two projects. So, the median is 0, which is expected, but we have many try blocks with many potentially recoverable exceptions that were propagated. Total for reference Propagated for reference Explain what the plot means.
- #15 These are exception types that we observed in our study. -Burden means: Have to learn all the types: know what they mean and when and how to handle it. C#: 136 Java: 501
- #16 Medians: C#: 27.78% 40.48% 47.62% - 42 Java: 21.74% 30.43% 39.53% - 80 Other thoughts: prevalence is not same across projects either, varies a lot. C#: 18 to 97 Java: 46 to 249 IOException for example has 322 (out of 1,645 ~20%) for Sharpdevelop, and 190 (out of 700 ~27%) for Spring. Remove the colors. Change Y axis, make it larger. Add aspect in the bottom. Change to text only, 1, <2, <3 ...
- #17 Complexity: have to check more methods Uncertainty: not sure what is being handled, which method is being handled IO Exception can actually mean 5 other types of exceptions. File Not Found example. Affect testers: multiple possible paths to be properly tested. This type of exception is higher than average number of methods.
- #18 Total: C#: 7,638 Java: 28,854 CHange to box to highlight numbers only.
- #19 Previous work talked about missing documentation. This usually what they looked at. Doc in comments: is what is missing. Automated tool gets the others. Method declaration is Java only. Make sure is API/library javadoc. Make transparency in the whole thing.
- #20 No documentation -> no problem. Risk can be mitigated with automated tool. Repeat that this is external! API, libraries. Doc that might be available without source code, on the web or xml files provided.
- #21 C# is not Java. A difference is the fact that forces the developers to explicit handle some kind of exceptions or propagate it. C# doesn’t. They are called checked exceptions in Java. slide 20, the motivating verbal line of the slide is weak. Add the checked exception explanation, verbal only.
- #22 Here we measure the % of possible exception that is handled with each action. As we can see java has more for these two actions. This makes us think that this is caused by forcing developers to handle. Developers might not know exactly how to handle, but they need to implement something. In this case, these actions are not quite handling, but more like ignoring it, or leaving it for later. More in Java, most cases. Mention checked exceptions. Throw new and Todo are like ignore, and move forward, not a good sign. Continue is for when inside loops. Remove continue!
- #23 motivation bottom bar