Re: Q: flowgraphs and exceptions (newbie)

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.


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.
--
James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
--

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