home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16669 < prev    next >
Encoding:
Text File  |  1992-11-20  |  3.3 KB  |  77 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!swillden
  3. From: swillden@news.ccutah.edu (Shawn Willden)
  4. Subject: Re: question on REFERENCES
  5. Message-ID: <1992Nov20.195725.3009@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: <5239@holden.lulea.trab.se>
  10. Date: Fri, 20 Nov 92 19:57:25 GMT
  11. Lines: 64
  12.  
  13. jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. : swillden@news.ccutah.edu (Shawn Willden) writes:
  15.  
  16.     [ Much stuff deleted ]
  17.  
  18. : : How is this different from a test for NULL?  The syntax may be slightly
  19. : : cleaner but not much is really gained by this approach.
  20. : 
  21. : You can often arrange things so that it is safe to attempt quite a few
  22. : function calls without checking anything at all (the first error is
  23. : safely stored away in a global variable).  If on the average you make
  24. : a few (say five) function calls before testing, you get a significant
  25. : reduction in the number of error tests, making the real algorithm more
  26. : easily recognizable.
  27.  
  28. Where this can be arranged, I would say it's a good idea.
  29.  
  30. : : Something must
  31. : : still be returned and that something will be invalid if the function 
  32. : : fails.  Why is the programmer more likely to remember to test an error
  33. : : flag than to test a returned pointer against NULL?
  34. : 
  35. : Because the error flag does not go away.  A later check will detect the
  36. : error.  Often this is quite acceptable, especially if the error is very
  37. : rare.  Also, you can arrange for checking the error flag at program
  38. : termination.  Any unhandled error at program exit can then be reported.
  39. : Similarly, if an object keeps an internal error state, then its
  40. : destructor should check the error state.  If there is an error, the destructor
  41. : should report it when the object goes out of scope (the iostream classes
  42. : do not do this, but IMHO they should).
  43.  
  44. Again, these are useful options.
  45.  
  46.  [...]
  47.  
  48. : : In addition, it requires all code
  49. : : that uses an object to test its goodness and then take appropriate
  50. : : action if not.  In many cases it is more convenient to design
  51. : : the object such that a given instance is always valid and to just avoid
  52. : : creating invalid ones.
  53. : 
  54. : Yes, and a nice variation is to return an object that checks the
  55. : "goodness" flag itself, and performs safe default actions if it
  56. : is an invalid object.  Sometimes this can be programmed by returning
  57. : an object of a subclass of the return type (which is a reference),
  58. : that overrides virtual functions appropriately.
  59.  
  60. This is an interesting variation that hadn't occurred to me.  It
  61. would have to be used carefully, though, because in many cases the
  62. value returned from a function is copied into another object instead
  63. of being used directly.  How often have you found this approach 
  64. worthwhile?  It seems to me that this would be a more useful option
  65. if you return a pointer, which you could, of course, guarantee to be
  66. non-NULL.
  67.  
  68. : -- 
  69. : --------------------------------------------------------------------------
  70. : | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  71. : | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  72. : --------------------------------------------------------------------------
  73.  
  74. --
  75. Shawn Willden
  76. swillden@icarus.weber.edu
  77.