home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18164 < prev    next >
Encoding:
Text File  |  1992-12-18  |  3.9 KB  |  88 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!swillden
  3. From: swillden@news.ccutah.edu (Shawn Willden)
  4. Subject: Re: Complexity in the eyes...V2.0
  5. Message-ID: <1992Dec18.001800.4373@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: University of Utah Computer Center
  8. X-Newsreader: Tin 1.1 PL3
  9. References: <1992Dec17.042207.8150@tagsys.com>
  10. Date: Fri, 18 Dec 92 00:18:00 GMT
  11. Lines: 75
  12.  
  13. andrew@tagsys.com (Andrew Gideon) writes:
  14. : 
  15. : Almost a month ago, I tried to start a new thread on the topic
  16. : of "complexity".  I assume that everyone agrees that a goal of
  17. : software engineering should be the reduction of complexity.  But
  18. : what I have recently seen is that the metrics by which complexity
  19. : is measured appear to be very subjective.
  20. : 
  21. : There were some very interesting comments, but - perhaps because I
  22. : fell way behind in my net-readership - the thread died a quiet
  23. : death.  I'd like to try again, in this case with a specific example.
  24. : 
  25. : Anyway, this is getting long, and I want to write my example up.
  26. : My example is a problem and two solutions: mine and my coworker's.
  27. : The question that I have is: which do you (plural) prefer (for any
  28. : reasons), and why?
  29. : 
  30. : The problem: moving errors around.  This includes moving errors
  31. : between applications, but it also includes the conventional problem
  32. : of passing errors up through a sequence of procedure calls.
  33. : 
  34. : My solution (well, I don't claim that the original idea was mine):
  35. : an error stack class.
  36.  
  37. [ Description deleted ]
  38.  
  39. : My coworker thinks this complex.  He'd prefer returning an integer.
  40. : The integer is an offset into an array of error messages.  If there
  41. : are multiple modules (when are there not?!), use one byte as a module
  42. : number to determine the specific array, and another byte as the offset.
  43. : 
  44. : He doesn't even want this encapsulated in a class, as that would
  45. : "make it more complex."
  46.  
  47. Complexity aside, unless I misread your post, your colleague's
  48. solution doesn't provide the same functionality as yours since it
  49. doesn't allow tracing of many levels of error messages (much less the
  50. log feature).  Increased functionality nearly always implies more
  51. complexity.  
  52.  
  53. If we add a stack to his method to allow tracing of multi-level
  54. messages then they become more comparable.  However, the syntax is
  55. awful unless we also provide functions to manipulate it.  If we do
  56. that, we have produced the same effect as a class with public data,
  57. which we might as well make private, either by making it internal
  58. (static) to the module where the stack manipulation functions are
  59. defined or by remembering that we *are* using a C++ compiler and
  60. building the thing into a class.
  61.  
  62. So, by the time you make his technique do as much as yours the
  63. complexity is the same, or maybe even greater, since it now becomes
  64. the programmer's job to verify by hand that all those error codes
  65. match up to the right error strings.
  66.  
  67. Is the added functionality worth the added complexity?  IMO, yes!
  68. Anything that aids in debugging and does not cost too much (in terms
  69. of syntax and complexity in the places where it is used) is useful.
  70.  
  71. I think the other programmers may not have wanted to use your error
  72. stack class because of laziness; they didn't want to have to think
  73. that much about errors.  In your words: Error handling behavior is
  74. "stuck on" rather than "designed in".
  75.  
  76. :  -----------------------------------------------------------
  77. : | Andrew Gideon              |                              |
  78. : | Consultant                 |                              |
  79. : |                            |   TAG Systems inc.           |
  80. : | Tel: (201) 890-7189        |   D2-181 Long Hill Road      |
  81. : | Fax: (201) 890-1581        |   Little Falls, N.J., 07424  |
  82. : | andrew@tagsys.com          |                              |
  83. :  -----------------------------------------------------------
  84.  
  85. --
  86. Shawn Willden
  87. swillden@icarus.weber.ed
  88.