home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12784 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  3.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!doug.cae.wisc.edu!umn.edu!nano!kotula
  2. From: kotula@nano.cs.umn.edu (Jeff Kotula)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Return value for the constructors.
  5. Message-ID: <kotula.714615837@nano>
  6. Date: 24 Aug 92 00:23:57 GMT
  7. References: <1992Aug19.231926.28218@sunb10.cs.uiuc.edu> <2273@devnull.mpd.tandem.com> <matt.714318343@centerline.com> <2284@devnull.mpd.tandem.com> <matt.714407976@centerline.com>
  8. Sender: news@news2.cis.umn.edu (Usenet News Administration)
  9. Distribution: usa
  10. Organization: University of Minnesota
  11. Lines: 51
  12. Nntp-Posting-Host: nano.cs.umn.edu
  13.  
  14. In <matt.714407976@centerline.com> matt@centerline.com (Matt Landau) writes:
  15.  
  16. >The fact that both of these approaches leave you with the potential for
  17. >using an incompletely initialized object (the very thing constructors in
  18. >C++ were supposed to prevent!) points to a basic shortcoming in most of
  19. >the current implementations of the language.  
  20.  
  21. Do any languages handle this cleanly?  None leap to mind...
  22.  
  23. >The underlying point is that without a decent exception system, there 
  24. >is **NO** good way to deal with the problem of constructor failures.  
  25. >There are several different not-so-good ways to choose from; which one 
  26. >you choose depends on the nature of the system you're writing.
  27.  
  28. >Even *with* a decent exception system, the problem doesn't just go away.
  29. >Exceptions provide a mechanism and a framework within which one can deal
  30. >with this problem (as well as many other problems).  The design skills
  31. >and engineering discipline needed to use exceptions both correctly and 
  32. >robustly are still not to be underestimated.
  33.  
  34. Absolutely.  The approach you've outlined is what I've been using and it
  35. seems to work pretty well.  You're final point is important because I've
  36. found that programmers dislike dealing with error situations and tend
  37. to simply ignore them.  All the discussions elsewhere on how to improve
  38. software quality are a bit premature until we can overcome this tendency.
  39.  
  40. Another aspect of this problem hasn't been discussed at all: what about
  41. operator overloading?  Unless no operator functions can fail (probably
  42. unlikely in anything more complicated that a numerical type) you can't
  43. really use operator overloading and check for errors.
  44.  
  45. One way you could is to (as has been mentioned) have a status code (a bit
  46. will generally not be enough information to recover from an error) in the
  47. object and *propogate* errors back to the final result-object of the
  48. expression.  This is Ugly.  Are programmers going to check the status of
  49. an object resulting from an expression when 50%(?) of all malloc or new
  50. calls are not verified?
  51.  
  52. Anyway, the language that solves this problem elegantly and robustly is
  53. probably a long way off, so I think we need to come up with useful
  54. techniques and programming practices rather than rely on a new feature in
  55. a language that follows a tradition of ignoring the problem.
  56.  
  57. 2 cents.
  58.  
  59. object
  60. --
  61. -------------------------------------------------------------------------------
  62. jeff                            |     "Dismiss whatever insults your own soul."
  63. kotula@cs.umn.edu               |              Walt Whitman
  64. -------------------------------------------------------------------------------
  65.