home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12668 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.3 KB

  1. Path: sparky!uunet!kithrup!hoptoad!decwrl!mips!swrinde!zaphod.mps.ohio-state.edu!usc!news.bbn.com!news.bbn.com!brazile
  2. From: brazile@soir.bbn.com (Robert Brazile)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Return value for the constructors.
  5. Message-ID: <BRAZILE.92Aug20170044@soir.bbn.com>
  6. Date: 20 Aug 92 22:00:44 GMT
  7. References: <1992Aug19.163545.25066@sunb10.cs.uiuc.edu>
  8.     <1992Aug19.175852.38459@watson.ibm.com>
  9.     <1992Aug19.231926.28218@sunb10.cs.uiuc.edu>
  10.     <2273@devnull.mpd.tandem.com> <matt.714318343@centerline.com>
  11.     <1992Aug20.170524.3452@sunb10.cs.uiuc.edu>
  12.     <matt.714332315@centerline.com>
  13. Distribution: usa
  14. Organization: Bolt Beranek and Newman, Cambridge, Mass.
  15. Lines: 32
  16. NNTP-Posting-Host: soir.bbn.com
  17. In-reply-to: matt@centerline.com's message of 20 Aug 92 17:38:35 GMT
  18.  
  19. In article <matt.714332315@centerline.com> matt@centerline.com (Matt Landau) writes:
  20.    [Also, having worked on a large software system that used exceptions as
  21.    a primary means of error reporting and recovery, I'm not convinced that 
  22.    it's the panacea some people seem to think it will be.  Dealing with
  23.    exceptions correctly in large systems rapidly becomes tedious and error
  24.    prone itself.]
  25.  
  26. Having worked on the large software system to which Matt refers, I can
  27. verify what he says. In particular, reuse becomes tricky in that the
  28. piece of code you steal^H^H^H^H^Hreuse (or just call from a library)
  29. may surprise you - even if the exceptions it throws are documented and
  30. you've covered them, code upon which it depends might throw exceptions that
  31. it doesn't handle for you. If they're uncommon enough, you might not
  32. find out for a long time. Which means you pass that problem on to any
  33. code that calls your new routine.
  34.  
  35. That shouldn't happen in well-designed code, I hear you cry. Well,
  36. that's true, but in a large and/or complex system it WILL happen.
  37.  
  38. Having exceptions is no worse than the current situation (trying to do
  39. everything by returning NULL pointers, or [shudder] global error
  40. codes) and is actually preferable because it's more flexible and helps
  41. with signalling errors in (hopefully simple) constructors. I just want
  42. to point out that it's not a panacea - it's doesn't even make things
  43. particularly easier.
  44.  
  45. Robert Brazile
  46. Bolt Beranek and Newman
  47. --
  48. Robert Brazile                    brazile@bbn.com
  49. Bolt Beranek and Newman Inc.            +1 (617) 873-2403
  50. Cambridge, Massachusetts
  51.