Re: Q: flowgraphs and exceptions (newbie)

To really represent them (at the module level) would require having an
"if error goto handler" type branch after every statement and expression
(and partial expression).


This could lead to a really nasty graph...


It really depends on what you intend to do with the graph -- are you
going to use it to understand the flow of the module, or as input to
some other tool that needs a very realistic view of the module?


For the Visual Basic parser I've worked on at McCabe & Associates, we
had a similar issue with the
    ON ERROR GOTO
statement. Realistically, this would create an "if error then goto
handler" branch after every statement/expression/partial expression that
could cause an error.


This seemed like the wrong thing to do for our flowgraphs. On the one
hand, we wanted to show that the handler code was invoked from
somewhere; on the other hand, we didn't want to make the module appear
overly complex.


If we had added extra tests/branches after everything that could cause
an error to be raised, cyclomatic complexity would increase
significantly and it would appear to the end user that they had some
very unstructured code. Bottom line -- the users would associate the
error handlers with bad coding practice.


We decided to add a single, dummy condition at the ON ERROR statement.
This condition basically added a branch to the following statement and
another branch to the handler code. This made the handler code appear
in the flowgraph, but only added 1 to the cyclomatic complexity of the
module. It isn't a "perfect" view of what the code is doing, but it
helps understanding of the code (and also has the nice side-effect of
linking the ON ERROR statement to the handler, showing where handlers
are turned on and off.)


If your flowgraphs are for assisting understanding of a module, you may
want to consider doing something similar with the "try" statement in C++
or Java. If for some other purpose that requires a realistic flow view,
you'll have to do some very careful analysis of what code can generate
which exceptions, and add conditions to branch to the handler
appropriately.


BTW: Not a silly question -- this can be a really sticky issue...


Good luck!
Scott




> What are useful ways of representing (C++/Java-style) exceptions and
> their handlers in flowgraphs?
--
Scott Stanchfield McCabe & Associates -- Columbia, Maryland
--

Return to the comp.compilers page.
Search the comp.compilers archives again.