From: swillden@news.ccutah.edu (Shawn Willden)
Subject: Re: Complexity in the eyes...V2.0
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Fri, 18 Dec 92 00:18:00 GMT

andrew@tagsys.com (Andrew Gideon) writes:
: 
: Almost a month ago, I tried to start a new thread on the topic
: of "complexity".  I assume that everyone agrees that a goal of
: software engineering should be the reduction of complexity.  But
: what I have recently seen is that the metrics by which complexity
: is measured appear to be very subjective.
: 
: There were some very interesting comments, but - perhaps because I
: fell way behind in my net-readership - the thread died a quiet
: death.  I'd like to try again, in this case with a specific example.
: 
: Anyway, this is getting long, and I want to write my example up.
: My example is a problem and two solutions: mine and my coworker's.
: The question that I have is: which do you (plural) prefer (for any
: reasons), and why?
: 
: The problem: moving errors around.  This includes moving errors
: between applications, but it also includes the conventional problem
: of passing errors up through a sequence of procedure calls.
: 
: My solution (well, I don't claim that the original idea was mine):
: an error stack class.
 
[ Description deleted ]

: My coworker thinks this complex.  He'd prefer returning an integer.
: The integer is an offset into an array of error messages.  If there
: are multiple modules (when are there not?!), use one byte as a module
: number to determine the specific array, and another byte as the offset.
: 
: He doesn't even want this encapsulated in a class, as that would
: "make it more complex."

Complexity aside, unless I misread your post, your colleague's
solution doesn't provide the same functionality as yours since it
doesn't allow tracing of many levels of error messages (much less the
log feature).  Increased functionality nearly always implies more
complexity.  

If we add a stack to his method to allow tracing of multi-level
messages then they become more comparable.  However, the syntax is
awful unless we also provide functions to manipulate it.  If we do
that, we have produced the same effect as a class with public data,
which we might as well make private, either by making it internal
(static) to the module where the stack manipulation functions are
defined or by remembering that we *are* using a C++ compiler and
building the thing into a class.

So, by the time you make his technique do as much as yours the
complexity is the same, or maybe even greater, since it now becomes
the programmer's job to verify by hand that all those error codes
match up to the right error strings.

Is the added functionality worth the added complexity?  IMO, yes!
Anything that aids in debugging and does not cost too much (in terms
of syntax and complexity in the places where it is used) is useful.

I think the other programmers may not have wanted to use your error
stack class because of laziness; they didn't want to have to think
that much about errors.  In your words: Error handling behavior is
"stuck on" rather than "designed in".

:  -----------------------------------------------------------
: | Andrew Gideon              |                              |
: | Consultant                 |                              |
: |                            |   TAG Systems inc.           |
: | Tel: (201) 890-7189        |   D2-181 Long Hill Road      |
: | Fax: (201) 890-1581        |   Little Falls, N.J., 07424  |
: | andrew@tagsys.com          |                              |
:  -----------------------------------------------------------

--
Shawn Willden
swillden@icarus.weber.ed