Systems and methods for visualization of exception handling constructs

Disclosed are various embodiments for visualization of exception-handling constructs. In one embodiment, among others, a system includes at least one computing device; a program maintained in a memory accessible to the at least one computing device; and logic executable in the at least one computing device configured to analyze the program to determine exception-handling information; generate a graphical user interface based upon the exception-handling information; and provide the graphical user interface for display on a display device.

BACKGROUND

Object-oriented programming languages, such as Java or C#, provide native constructs for handling exceptions that occur during a program's execution. These constructs specify mechanisms to define exceptions, to raise exceptions, to address exceptions by executing designated code, and to return to the regular control flow of the program after an exception is raised. While developers make frequent use of these exception handling constructs, the mechanisms to handle an exception are not applied locally within a program, but are scattered across different methods, classes, or even packages. Despite the native support of programming languages, exception handling constructs and their behaviors at runtime are often the least understood parts of a program. Visualization of exception handling can aid in understanding the complex mechanisms of exception handling in a large software system, allowing the developer to efficiently maintain, test, and debug the system.

DETAILED DESCRIPTION

Disclosed herein are various embodiments of methods related to visualization of exception-handling constructs. Reference will now be made in detail to the description of the embodiments as illustrated in the drawings, wherein like reference numbers indicate like parts throughout the several views.

Object-oriented programming languages utilize exceptions to handle the occurrence of conditions that change the normal flow of program execution. In general, an exception is handled by saving the current state of execution and switching (or throwing) the execution to a specific subroutine or exception (or catch) handler. There exist two different kinds of exceptions: exceptions that are explicitly thrown in the code (checked exceptions) and exceptions generated by the virtual machine at runtime, such as out of memory exceptions (unchecked exceptions). In the current disclosure, exception-handling constructs are discussed in the context of the Java programming language. However, one of ordinary skill in the art would understand that the principles discussed in relation to Java can be expanded to include other object-oriented programming languages.

The following program illustrates the way in which exceptions are used in a Java program that computes the factorial of an integer. The class definition of the exception and the method to read the input data are omitted because of space constraints. This program will be used for the discussion of exception-handling constructs.

In Java, checked exceptions are modeled as regular objects and can be raised using the throw statement (e.g., line 13 of the above program). To handle exceptions, Java provides try, catch, and finally statements. A try block (e.g., lines 3-6) contains a sequence of statements and is executed until an exception is thrown or until the block is completed. A try block is followed by one or more catch blocks, by a finally block, or by both. A catch block (e.g., lines 7-9) is associated with a try block, defines the type of the exception it handles, and contains a set of statements. A finally block (e.g., line 10-11) is also associated with a try block and contains a set of statements.

If an exception occurs in a try block, the associated catch blocks are checked for a matching type (i.e., for the exception type or a superclass of the exception type). If a matching catch block is found, its body is executed and the program continues its execution with the statement following the try block. Otherwise, the call stack is searched for a matching catch block. If a match is found, the program continues with the execution of that catch block's code; otherwise, the program terminates. If a finally block is present in a try-catch-finally sequence, its code is always executed: either after the try block (if no exception is raised or no matching catch block is found for a raised exception) or after the catch block (if a matching catch block is found for a raised exception). Thrown exceptions can be deactivated by a matching catch handler or by a finally block containing a statement that transfers the control flow outside the finally block (e.g., a return or a continue statement).

FIG. 1is a flow diagram100illustrating a method for visualization of exception flows and the related exception-handling constructs within a program. Initially, in block110, a program is analyzed to determine the exception-handling constructs and their relationships within the program. An analysis tool, operating on a computer system, is used to analyze the program to determine the exception-handling construct information (e.g., flow of the exception and code location). The flow of an exception consists of two parts: (1) the flow from the exception's type definition to reachable throw statements and (2) the flow from those throw statements to reachable catch statements. A throw statement is reachable from a type definition if an execution path exists from the type definition to the throw statement; a catch statement is reachable from a throw statement if an execution path exists from the throw statement to the catch statement and no statement along the path deactivates the raised exception. Analysis techniques related to exception flow are presented in “Exception-chain Analysis: Revealing Exception Handling Architecture in Java Server Applications” by C. Fu and B. G. Ryder in the Proc. of the ICSE 2007, “Automated Support for Development, Maintenance, and Testing in the Presence of Implicit Control Flow” by S. Sinha, A. Orso, and M. J. Harrold in the Proc. of the ICSE 2004, and “Static Analysis to Support the Evolution of Exception Structure in Object-Oriented Systems” by M. P. Robillard and G. C. Murphy in the ACM Trans. on Software Eng. and Methodology, April 2003, all of which are incorporated herein by reference.

In block120, a graphical user interface (GUI) is generated by a computer system based upon the determined exception-handling information. The GUI provides three views, each offering a different perspective on exception flows and the related exception-handling constructs. The views represent the exception-related information with three levels of detail: a high-level (quantitative) representation that provides quantitative information about exception constructs with respect to overall program structure, an intermediate-level (flow) view focuses on flow information of different exception-handling constructs, and a low-level (contextual) representation that provides contextual details with respect to each exception-flow within the program. The intermediate view provides more specific details than the high-level quantitative view but abstracts the contextual details of the low-level view. This approach lets a user focus only on the flow details of the exception-handling constructs in the program (type, throw, catch, and finally). The intermediate-level view not only facilitates concentrating on the exception-handling constructs and their flow information, but also provides a smooth mental transition from the general high-level quantitative information to the specific low-level contextual information.

The GUI is provided for display on a display device in block130. The user may then interact with the GUI to gather general insights that developers might need to better understand exception-handling constructs within the context of the analyzed program. For example, the tri-level visualization helps users to understand cyclic dependencies, tight coupling among structural elements, exception construct concentration in a particular element, and structural complexity of the program with respect to exceptions. High-level views are useful to see information about the number of exceptions of a particular type within a method, a class, or a package. Lower-level visualizations showing detailed contextual information about an exception's origin, its type, and its complete propagation path aid in better understanding of the exception flows. Additionally, such views also aid in quickly understanding change-impact details (e.g., how modifying a catch block's type may affect the set of exceptions it may handle).

InFIGS. 2-4, exemplary embodiments of the three exemplary views of visualization (quantitative, flow, and contextual) are presented with respect to a version of the Java program nanoxml3 to present examples of the different views. The nanoxml program has approximately 2700 lines of code, three packages, five classes, and 85 methods. The packages include the default package in the program and two other packages designated as nanoxml and nanoxml.sax.

FIG. 2illustrates an exemplary embodiment of the high-level qualitative view200of the GUI ofFIG. 1in accordance with the present disclosure. The quantitative view200provides information about throw-catch pairs at different structural levels of a program's hierarchy (i.e., package level, class level, and method level). This high-level view200also gives an overview, in the form of a matrix210, of the exception dependencies between structural elements. The columns in the matrix210represent structural elements220containing throw statements and the rows represent structural elements230containing catch statements. Thus, a cell240(i.e., column-name, row-name) in the matrix represents throw-catch pairs between the two intersecting structural elements220and230. In other embodiments, the columns in the matrix210represent structural elements containing catch statements and the rows represent structural elements containing throw statements.

In the embodiment ofFIG. 2, a circle250in a cell240indicates that there exists at least one throw-catch pair between the two intersecting structural elements220and230. In some embodiments, the visualization uses distinct shades of a color to provide relative information of the throw-catch pair density. Alternatively, a color scale including a different color associated with each level may be utilized. The shade or color may be allocated using a three step process: (1) calculate the range of the number of throw-catch pairs, (2) partition this range into a predetermined number of discrete sets of values, and (3) assign one shade or color to each set such that the darkness of the shade or the color scale increases with the set values. In other embodiments, the color or shade scale is predetermined. In the example ofFIG. 2, the shading scale260is divided into five discrete sets. Thus, a circle250with the darkest shade indicates that the intersecting structural elements220and230are strongly exception-dependent on each other.

In some embodiments, the high-level visualization200uses a static color scheme where the number of throw-catch pairs in the entire program under consideration is used to calculate the range of number of throw-catch pairs. This choice of color scheme assures that the color assignment is consistent across the different structural levels. In some cases, however, using such a static scheme could result in most cells belonging to the same set of values and making them indistinguishable. To address this, other embodiments use a dynamic color scheme where the number of throw-catch pairs in the currently displayed set of packages, classes, or methods is used to calculate the range of number of throw-catch pairs. The dynamic color scheme may be an on-demand feature or automatically implemented by the GUI.

The quantitative view200ofFIG. 2is a plain design that does not display additional information in the circles250to allow the view to scale a reasonable size. In other embodiments, the circle250may include the display of information (e.g., the number of throw-catch pairs between intersecting structural elements) or, alternatively, the circle250may be replaced by the number of throw-catch pairs between the two intersecting structural elements220and230. Using cells240with a size of approximately 15×15 pixels, the quantitative view200can display a matrix210of up to 50 packages at standard screen resolution when the labels for the columns elements220are presented vertically.

The exemplary embodiment ofFIG. 2shows the quantitative view200for nanoxml at the package level: each of the three rows and columns in the matrix represents one package in the subject. The first package, labeled “(default)”, represents the default package in the program. The two other packages are labeled as “nanoxml” and “nanoxml.sax”. The circle250at cell240between the two intersecting structural elements [nanoxml, nanoxml.sax]220and230indicates that the package nanoxml220may throw exceptions that are caught by catch blocks within the package nanoxml.sax230. Similarly, the circle between the two intersecting structural elements [nanoxml, nanoxml] indicates that the package nanoxml220may throw exceptions that are caught by catch blocks within the same package (nanoxml). With the exception-dependency information that the qualitative view200provides, a user can get an overview of how well the program is implemented with respect to exception-handling constructs. For example, if all circles on the package level are on the top-left to bottom-right diagonal in the matrix210, the program has no cross-package dependencies in terms of exceptions.

The qualitative view200may also be implemented at a class level or at a method level. The qualitative view200may be toggled or switched between levels. At the class level, each of the rows and columns in the matrix represents a class. At the class level, the qualitative view200visualizes the catch-throw pairs between some or all of the classes in the program at the intersecting cells. Similarly, at the method level, the qualitative view200visualizes the catch-throw pairs between methods in the program. In some embodiments, all methods of the program are displayed, while in others, methods of selected classes are displayed. Throw-catch pairs within the same class or between different classes may be visualized. For example, the methods of one or more classes may be displayed as throws and the methods for the same or a different combination of classes may be displayed as catches. Because the matrix in the quantitative view200can be large, in some embodiments, filters can be used to address scalability. For example, filters may be selected to (1) filter structural elements by their names (e.g., consider only elements that have the term “parse” in their names), (2) reduce the size of the matrix by showing only the rows and columns that have at least one entry, and/or (3) select specific elements of interest.

The GUI can provide for a plurality of operations that allow the user to interact with the quantitative view200. For example, moving the mouse to place the cursor icon over a cell240may cause a tooltip270to display with exception-handling information such as, but not limited to, the actual number of throw-catch pairs between the two intersecting structural elements. In the exemplary tooltip270ofFIG. 2, there are 11 throws in the nanoxml.XMLElement class that may be caught by catch blocks in the nanoxml.sax.SAXParser class. Selecting an element may allow the user to view different level views. For example, a single click can select an element (multiple selections are possible using the CTRL key function), and a double click can switch to the next lower level while keeping the selected elements in focus. In such a scheme, a SHIFT double click can switch to the next higher level (using the up-arrow of the SHIFT key as metaphor). The user may make multiple selections by using a “rubberband” mechanism (e.g., using a mouse to press and drag).

To help the user navigate between different level views of the GUI, the quantitative visualization200may use color variations on the row and column headers of the matrix210(i.e., the topmost row280and the leftmost column290in the matrix210) to indicate differences in their levels. For example, dark orange for the package level, light orange for the class level, and cream for the method level. The selected color variations belong to the same color group and take the level hierarchy into account (e.g., the higher the level is in the hierarchy, the darker is its color).

While the quantitative view200displays information about the throw-catch pairs at different structural levels, it does not provide information about the types and flows of the exceptions.FIG. 3illustrates an exemplary embodiment of the intermediate-level flow view300of the GUI ofFIG. 1in accordance with the present disclosure. The flow view300provides further details about exception-handling constructs by showing a graph310(i.e., the exception-flow graph) that includes nodes representing four components of exception handling: exception types320, throw statements330, catch statements340, and finally statements (not shown inFIG. 3).

The flow view300represents the components using different shapes: triangles for type nodes320, squares for throw-statement nodes330, and circles for catch-statement nodes340. In addition, octagons may be used for finally-statement nodes. In other embodiments, a different combination of shapes may be used to represent the nodes. Circles with a white hole in the center (e.g., circle350) represent empty catch handlers (i.e., catch blocks that do not contain any executable statements). An edge360between a type node320and a throw-statement node330indicates that an exception of that type reaches that throw statement in the program. If an exception type is not explicitly defined but the throw statement throws the exception directly using its constructor, the edge360between the throw node330and the type node320is colored differently (e.g., gray instead of black) to indicate that no explicit flow exists. An edge370between a throw-statement node330and a catch-statement node340indicates that an exception thrown at that throw statement can reach that catch statement.

In the embodiment ofFIG. 3, all nodes (320,330, and340) have the same coloring except for an exit node380, which has a different color indicating that it is a special kind of catch-statement node, or a finally-statement node, which has a different color indicating that it has at least one path that deactivates an exception (e.g., using a return statement). For example, all nodes (320,330, and340) may be colored green except for the exit node380or a finally-statement node, which may be colored in red. Edges370from throw nodes330reaching an exit node380indicate that exception occurring at those throw statements may go uncaught and thus, reach the program's exit. In addition, in some embodiments, inappropriate coding patterns such as, but not limited to, empty catch handlers, deactivations of exceptions in finally blocks, rethrows of exceptions in catch blocks, and exceptions that reach the program's exit are highlighted.

A hierarchical graph layout algorithm may be utilized to determine the layout for the exception-flow graph310. If no finally-statement is present in the exception flow, the graph310consists of three layers of nodes, which are assigned to one of the three layers: all type nodes320are assigned to the top layer, all throw-statement nodes330are assigned to the middle layer, and all catch-statement nodes340are assigned to the bottom layer. Within a layer, the nodes may be sorted to minimize edge crossings using a heuristic algorithm. In some embodiments, the names of some or all of the nodes may be displayed. The node names may be displayed over the edges or may be toggled to display behind the edges or, alternatively, removed from the view.

The exemplary embodiment ofFIG. 3shows the flow view300for the program nanoxml. In some embodiments, flow view300can be reached by selecting both circles in the quantitative view200ofFIG. 2and switching to the flow view300. The highlighted path (shown with thicker edges inFIG. 3) shows that an exception of type “java/io/FilenotFoundException” can be thrown from the throw-statement330at line2038in method nanoxml/XMLElement.addedMethod and this exception can be caught at the catch-statement at line2039in method nanoxml/XMLElement.addedMethod.

In the flow view300, users can select nodes or edges using the cursor icon and a single mouse click. Selecting a node (320,330,340) highlights all exception-flow paths (360,370) to which the selected node belongs. Selecting an edge (360,370) highlights only the two adjacent nodes. Selection of multiple nodes and/or edges is possible using the CTRL key function.

The flow view300may be provided with different layouts of the graph310. For example, the nodes (320,330,340) are arranged to minimize edges crossings in the graph310. In other layouts, the nodes (320,330,340) may be clustered accordingly to their package and class structure. In some embodiments, the nodes (320,330,340) are clustered by class and ordered by the line number of the statements they represent. As can be seen inFIG. 3, a single catch-statement node340can catch throws from multiple throw-statement nodes330and a throw-statement node330can throw to multiple catch-statement nodes340. Furthermore, the exception from all throw-statement nodes330except one may reach the program exit node380and there seem to be some unreachable catch handlers.

To learn more about the unreachable catch handlers, the flow view300may be focused on the flow to catch handlers while also taking rethrows into account. Catch handlers may rethrow a caught exception, which can be indicated by a dotted or dashed line from the catch node340to the throw node330. In some embodiments, the rethrow may be colored (e.g., red) to distinguish it from other edges370. In this way, catch handlers that catch runtime exceptions and use a rethrow can be visualized.

The flow view300visually displays the exception-handling flow information to allow users to infer information about the statements represented by the nodes. For example, a catch-statement node340with several incoming edges370may indicate the impact of that catch block on the rest of the exception flow in the program. Many edges into a catch-statement node340can indicate that the node340represents a catch-statement that is responsible for handling a number of exceptions and thus, changing such a catch block may impact different parts of the program. In addition, tracing complete paths of a node tuple [type320, throw330, catch340] in the flow view300may help to determine the type of a catch block. For example, a catch-statement node340handling different types of exceptions implies that catch block's type is a supertype of all the exception types it handles.

The flow view300may also help in observing patterns in the flow of exceptions within a program. For instance, edges370from one throw-statement node330to different catch-statement nodes340indicate that there are different paths that an exception at that throw-statement330may follow, depending on the program conditions. Three perspectives of an exception-flow graph310(each producing a subgraph of the exception-flow graph) may be selected to aid the user:1) a type-centric perspective with respect to a type-node definition statement sD: the node set of this subgraph consists of the set of defined type-nodes sDitself, all throw nodes that are reachable from sD, and all catch nodes that are reachable from those throw nodes;2) a throw-centric perspective with respect to a throw-node definition statement sT: the node set of this subgraph consists of the set of type-nodes that can reach the set of defined throw-nodes sT, sTitself, and all catch nodes that are reachable from sT; and3) a catch-centric perspective with respect to catch-node definition statement sC: the node set of this subgraph consists of the set of throw-nodes that can reach the set of defined catch-nodes sC, all type-nodes that can reach those throw nodes, and sCitself.
The edge sets of these perspectives are derived from the feasible control flow defined by the given node sets. The type centric perspective leads to two patterns: single type to single throw and single type to multiple throws. The throw centric perspective leads to four patterns: single type to single throw; multiple types to single throw; single throw to single catch; and single throw to multiple catch. The catch centric perspective leads again to two patterns: single throw to single catch and multiple throws to single catch. The different perspectives may be selected by a user through the GUI.

FIG. 4illustrates another exemplary embodiment of the intermediate-level flow view400of the GUI ofFIG. 1, which includes the visualization of finally statements. The program405inFIG. 4is used as an example to illustrate how finally statements are integrated in the flow view400. The program405includes three methods A, B, and C that are called in the try block of the main method. Method A throws an exception in a try block, the exception is caught in a catch block, the finally block is executed, and the method returns. Method B throws an exception and deactivates it using a return statement in the finally block. Method C throws an exception, executes the finally block, and the exception is caught in the main method.

The graph410of flow view400corresponds to the program405. One or more additional layers may be added to visualize the finally nodes. In the embodiment ofFIG. 4, two additional layers (between the throw and catch node layers and after the catch node layer) are added for the finally nodes450and455to reflect the two possible flows. If a try block has both a catch and a finally block, and the exception is caught in the catch block, then the finally block is executed after the catch block. If the catch block does not catch the exception (because the type does not match) or no catch block is present, the finally block is executed after the try block and before the control flow leaves the method. The leftmost nodes represent the flow in method A (throw430, catch440, finally455), the nodes in the middle represent the flow in method B (throw430, deactivation in finally450), and the rightmost nodes represent the flow in method C (throw430, finally450, catch440). As can be seen, because methods B and C are of the same type, they both flow from a single type node420.

FIG. 5illustrates an exemplary embodiment of a low-level contextual view500of the GUI ofFIG. 1in accordance with the present disclosure. While a flow view displays flow information about the exceptions at the statement level with respect to throw and catch statements, flow information in the presence of the statements' context with respect to the programs hierarchical structure (e.g., to which class and method a statement belongs) is not shown. The contextual view500provides information about the complete propagation path of an exception including the methods through which the exception may propagate before reaching the catch (i.e., methods that use the throw construct) by extending the exception-flow graph to show exception-propagation information in an exception-propagation graph510. This graph510is embedded in a hierarchical representation of the source code of the program.

In the exemplary embodiment ofFIG. 5, the hierarchy, representing the package, class, and method levels, is composed of three levels of rectangles embedded within each other. An outermost rectangle520represents a package, intermediate rectangles530represent the classes within the package, and innermost rectangles540represent the methods within these classes. To help the user navigate between different level views of the GUI, the contextual view500may use color variations to indicate differences in their levels as in the quantitative visualization200ofFIG. 2. For example, dark orange may be used for outermost rectangles520representing the highest package level, light orange may be used for the intermediate rectangles530representing the class level, and cream may be used for the innermost rectangles540representing the method level. The selected color variations belong to the same color group and take the level hierarchy into account (e.g., the higher the level is in the hierarchy, the darker is its color). Within the method rectangles540, the contextual view500visualization may display the method's code in a small font. Although the code may not be readable, the preserved line structures and indentations of the code help to quickly identify locations in the source code. In some embodiments, the GUI may allow a user to zoom in on the code text. Code outside of method blocks, such as the variable declaration and import statements, may be ignored because it does not directly relate to exception-handling constructs.

In some embodiments, a simple heuristic can be used to recursively compute the layout of the hierarchy of the contextual view500. The maximal height of an outermost rectangle520representing a package is defined using the available screen real estate of the GUI. Based on this maximal height, the technique computes the height of the intermediate rectangles530representing each class. The innermost rectangles540representing methods are arranged in columns within the intermediate class rectangles530. In some embodiments, the innermost method rectangles540may be wrapped accordingly to the maximal height. The intermediate class rectangles530may be arranged the same way in the outermost package rectangles520.

The exception-propagation graph510consists of nodes and edges. Nodes are exception-related or non-exception related. In some embodiments, exception-related nodes use the same color and shape representation as the associated flow view (e.g., flow view300ofFIG. 3): squares represent throw-statements nodes330, circles represent catch-statement nodes340, and octagons represent finally statements. For example, as with flow view300, the nodes may be colored green unless they are involved in an inappropriate coding pattern in which case they are colored red. Non-exception related nodes550, represented as smaller black circles, denote the methods within the propagation path of the exception flow. Edges560indicate the flow of the exception along its propagation path.

The exemplary contextual view500ofFIG. 5illustrates the propagation path of an exception across two packages. The contextual view500shows two packages, nanoxml and nanoxml.sax (outermost rectangles520aand520b, respectively), of the nanoxml program and their contained classes and methods. The embedded exception flow graph510shows that a throw (node330) in the method XMLElement.skipBogusTag (innermost rectangle540a) in package nanoxml (outermost rectangles520a) is caught by the catch block (node340) in method SAXParser.parse (innermost rectangle540b) in package nanoxml.sax (outermost rectangles520b) after it is propagated through five other methods. Embedding the exception flow graph510into the contextual view500of the entire source code helps the developer to maintain a mental model of the visualization when switching from one flow to another. Embedding graph510also lets the user visualize multiple flows at once and as such supports comparison. In addition, the propagation of catch-throw-finally and throw-finally relationships may be similarly depicted in the contextual view500of the program.

In some embodiments, moving the cursor icon over an element in the contextual view500displays further details of that element in a tooltip. For example, the name and line number may be displayed for throw-statement nodes330and catch-statement nodes340and the method name may be displayed for nodes550representing intermediate points in the propagation path. Similarly, information about a package, class, or method may be presented by selecting the appropriate rectangle.

The contextual view500aids the user in understanding how different parts of a program are involved in exception flows. For example, the contextual view500can show how any changes made, with respect to exceptions, to the intermediate methods involved in the exception-propagation path (e.g., removing a throw construct and introducing a catch block) may affect the flow of the exception. The contextual view500may also help to understand an inappropriate coding pattern such as a large distance between throw and catch pair. The exception-propagation path provides the context of this large-distance pattern by showing the methods through which the exception propagates and helps the developer to decide whether refactoring is necessary.

Because the approach may not scale for larger programs, a user may select to view a condensed contextual view that includes only methods that are involved in the exception flow.FIG. 6illustrates an exemplary embodiment of a condensed contextual view600. In the exemplary condensed contextual view600, a throw (node330) in method XMLElement.skipWhitespace (innermost rectangle620) in package nanoxml reaches the program exit (node380) after it is propagated through five other methods; only the methods involved in the propagation are shown in this condensed contextual view600.

A graphical user interface (GUI) may be used to implements the three views: qualitative, flow, and contextual.FIG. 7illustrates a view of a GUI700in accordance with an embodiment of the present disclosure. In the exemplary embodiment ofFIG. 7, the three views are integrated as three separate tabs701,702, and703in a single GUI display700. The GUI700allows a user to select one of the three visualizations (i.e., the quantitative view, the flow view, or the contextual view) using tabs701,702, and703. In other embodiments, two or more views may be simultaneously displayed by the GUI.

In addition, the left column of the exemplary GUI700provides five filters for controlling the three views:An Exception Type filter710that allows a user to select an exception type(s) for which details will be provided in the three views;Three location filters for throw-statements720, catch-statements730, and finally statements740that allow a user to select one or more structural elements to which the throw, catch, and finally statements belong. The related quantitative, flow and contextual views provide filtered information about the exception-handling constructs of the selected structural elements based upon the filter definitions; andA patterns filter750that allows a user to select a pattern and view exception flows that form the selected pattern. The patterns represent the six edge flow patterns discussed previously. In the embodiment ofFIG. 7, the top row of the patterns filter represents the patterns of single type to single throw751, multiple types to single throw752, and single type to multiple throws753. The bottom row of the patterns filter represents the patterns of single throw to single catch754, single throw to multiple catch755, and multiple throw to single catch756. This filter750is specific to the flow view and is disabled when one of the other views is used.

The GUI700may also provide two kinds of filtering mechanisms: filtering by selecting and interacting directly with the entities in one of the three views (as described previously) or filtering by using any combination of the five provided filters710-750. Because the three views in the embodiment ofFIG. 7are organized as tabs701,702, and703, it is possible to switch between the views while maintaining the same context defined by the filters. In other embodiments, two or more views may be simultaneously displayed by the GUI.

In the example ofFIG. 7, the tab702for the flow view has been selected. An exemplary flow view760for the nanoxml program is displayed with the focus on the edges. The flow view760shows that five of the six edge set patterns discussed above exist in the nanoxml program (the multiple types to single throw pattern is not present). The visualization of GUI700also shows that there exists only one empty catch handler (node350). Its code is shown in the editor view770located at the top of the GUI window700inFIG. 7.

Referring next toFIG. 8, shown is one example of a system that performs various functions related to visualization of exception handling constructs according to the various embodiments as set forth above. As shown, a processor system800is provided that includes a processor803and a memory806, both of which are coupled to a local interface809. The local interface809may be, for example, a data bus with an accompanying control/address bus as can be appreciated by those with ordinary skill in the art. The processor system800may comprise, for example, a computing device such as a desktop computer, laptop, personal digital assistant, server, or other system with like capability.

Coupled to the processor system800are various peripheral devices such as, for example, a display device813, a keyboard819, and a mouse823. In addition, other peripheral devices that allow for the storage of exception-handling information or program files may be coupled to the processor system800such as, for example, an external storage device829.

Stored in the memory806and executed by the processor803are various components that provide various functionality according to the various embodiments of the present invention. In the example embodiment shown, stored in the memory806is an operating system853and an exception visualization system856. In addition, stored in the memory806are various program files859and exception-handling information863. The program files859may be analyzed for visualization by the graphical user interface. The exception-handling information863may be associated with corresponding ones of the program files859. The program files859and the exception-handling information863may be stored in the external storage device829as needed.

The exception visualization system856is executed by the processor803in order to visualize exception-handling constructs as described above. A number of software components are stored in the memory806and are executable by the processor803. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor803. Examples of executable programs may be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory806and run by the processor803, or source code that may be expressed in proper format such as object code that is capable of being loaded into a of random access portion of the memory806and executed by the processor803, etc. An executable program may be stored in any portion or component of the memory806including, for example, random access memory, read-only memory, a hard drive, compact disk (CD), floppy disk, or other memory components.

The processor803may represent multiple processors and the memory806may represent multiple memories that operate in parallel. In such a case, the local interface809may be an appropriate network that facilitates communication between any two of the multiple processors, between any processor and any one of the memories, or between any two of the memories etc. The processor803may be of electrical, optical, or molecular construction, or of some other construction as can be appreciated by those with ordinary skill in the art.

The operating system853is executed to control the allocation and usage of hardware resources such as the memory, processing time and peripheral devices in the processor system800. In this manner, the operating system853serves as the foundation on which applications depend as is generally known by those with ordinary skill in the art.

Referring back toFIG. 1, shown is a flow chart100that may be viewed as depicting steps of an example of a method implemented in the processor system800(FIG. 8) for visualization of exception-handling constructs as set forth above. The functionality of the method as depicted by the example flow chart ofFIG. 1may be implemented, for example, in an object oriented design or in some other programming architecture. Assuming the functionality is implemented in an object oriented design, then each block represents functionality that may be implemented in one or more methods that are encapsulated in one or more objects. The exception visualization system may be implemented using any one of a number of programming languages such as, for example, C, C++, or other programming languages.