Re: Q: flowgraphs and exceptions (newbie)

Sounds like we have two complexity ideas at odds:


1) view of the written code
2) actual work being done/testing required


For analyzation/understanding/reverse-engineering of code, #1 is
probably the way to go.


For test coverage analysis, #2 is probably better.


We chose #1 because we wanted the customers to be able to view the code
and not be penalized for using an ON ERROR statement.


We may add an option someday to let the user decide, especially when
they are testing -- do they want the implicit paths listed so they can
test them and have coverage reported?


I agree with most of what you're saying here, and you're exactly right
about the customer being the bottom line. This is the first time we've
tried to handle error-handling constructs, and we'll have to see what
the customers think about it.


Later!
Scott


Scott Stanchfield <scooter@mccabe.com> writes:
|> 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.


James Kanze US/ESC 60/3/141 #40763 wrote:
> Why not? It is. There has been some discussion on this in
> comp.lang.c++.moderated. Exceptions do make the code significantly more
> complicated, precisely because the add complexity to the flow graph.
> This complexity is what makes analysis for exception safety difficult.
>
> The problem is in maintaining coherence in your data. Typically, the
> data must be coherent on entering (preconditions) and on leaving
> (postconditions) the function. The proof that this is so involves
> analysing all possible program paths. Exceptions do increase the number
> of paths you have to analyse.


|> 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.


> They do have some very unstructured code, at least by the conventional
> definition of structured code. (I'm thinking of the single entry/single
> exit rule here. Exceptions and other error handlers which do not or
> cannot resume generally result in leaving a block in the middle.)
>
> The real problem is, of course, what the customer wants to see. In
> general, for example, with C++ exceptions, it may be acceptable to
> maintain only partial data coherence (enough so that destructors can be
> called). Also, it may be possible for the programmer to prove that the
> exception cannot be triggered. To take your example concerning ON ERROR
> in Basic: if the programmer has done proper bounds checking on the input
> data, and the proper analysis of what he is doing, and overflow error
> cannot occur.
>
> IMHO, this is a real problem for a tool trying to analyse complexity at
> a module level. In theory, if I can get an exception from a called
> function, I have introduced an additional path in my program, and have
> really increased complexity. But how can the tool possibly know? As a
> simple example, a container class uses operator new to obtain its
> memory; this can throw bad_alloc. Unless, of course, I've replaced the
> new handler in main to simply abort if there is not enough memory. It's
> a strange sort of coupling, but the environment in which the function is
> used can affect its real complexity.
--
Scott Stanchfield McCabe & Associates -- Columbia, Maryland
--

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