home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / acorn / tech / 530 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.4 KB
  1. Path: sparky!uunet!decwrl!waikato.ac.nz!bwc
  2. From: bwc@waikato.ac.nz (Ug!)
  3. Newsgroups: comp.sys.acorn.tech
  4. Subject: Exception handling in C.
  5. Message-ID: <1992Nov9.135023.12048@waikato.ac.nz>
  6. Date: 9 Nov 92 13:50:23 +1300
  7. Organization: Vooniersity fo Kaiwato
  8. Lines: 43
  9.  
  10. I'd like to discuss a few things about what I am implementing at the moment,
  11. first among them being the issue of exception handling in C.
  12.  
  13. Exception handling is always a messy business, and C doesn't cope
  14. particularly well with it, although in fact I've yet to meet a language
  15. which does.
  16.  
  17. For those of you who don't know what exception handling is, it's what the
  18. language does when things go wrong.  For instance, what happens when you do
  19. a divide by zero?  Much of the exception handling is an academic question:
  20. with facilities built into the language, you are stuck with what you are
  21. given.  However, in your own code, you have some say over how you want to
  22. handle exceptional cases.
  23.  
  24. Three things I wanted to have with an exception handling facility were:
  25.  
  26. *  every module which raised an exception should include some facility for
  27.    coping with this exception (usually by displaying an error message to
  28.    the user).  This means that you should not get unhandled exceptions ever.
  29.    However, there should still be some fallback facility for handling
  30.    buggy code.
  31.  
  32. *  exceptions should be interceptable.  For instance, if I call a routine
  33.    to open a file, and the routine raises an exception if that file doesn't
  34.    exist, then an error message may not always be appropriate for that
  35.    situation.  I should be able to intercept that exception, and in this
  36.    case, decide not to raise an error.
  37.  
  38. *  exceptions should not alter the normal flow of code.  If you allow
  39.    an exception to land you somewhere else in the program, then you end
  40.    up with a mess that makes spaghetti look friendly.  Instead, exceptions
  41.    should be coped with in a manner resembling interrupt handlers.
  42.  
  43. Those were my base ideas for handling exceptions.  What I came up with was
  44. essentially each module registering a handler with an 'error' module.  The
  45. most recent registered handler is passed the exception first.  If it doesn't
  46. handle the exception, then the next most recent handler is called, and so on.
  47.  
  48. How do other people cope with exceptions?  Is there something I'm missing?
  49. I've noticed that my way of doing adds the additional ability to cope well
  50. with internationalisation, which is an added bonus.
  51.  
  52.                                 Ug!
  53.