home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!axion!rtf.bt.co.uk!duplain
- From: duplain@rtf.bt.co.uk (Andy Duplain)
- Newsgroups: comp.sys.acorn.tech
- Subject: Re: Exception handling in C.
- Message-ID: <1992Nov10.101651.3913@rtf.bt.co.uk>
- Date: 10 Nov 92 10:16:51 GMT
- References: <1992Nov9.135023.12048@waikato.ac.nz>
- Organization: BT Customer Systems, Brighton, UK
- Lines: 30
-
- In article <1992Nov9.135023.12048@waikato.ac.nz> bwc@waikato.ac.nz (Ug!) writes:
- >I'd like to discuss a few things about what I am implementing at the moment,
- >first among them being the issue of exception handling in C.
- >
- >Exception handling is always a messy business, and C doesn't cope
- >particularly well with it, although in fact I've yet to meet a language
- >which does.
-
- Exception handling should not be a part of any language -- it is
- part of the Operating System.
-
- [ stuff deleted ]
-
- >How do other people cope with exceptions? Is there something I'm missing?
- >I've noticed that my way of doing adds the additional ability to cope well
- >with internationalisation, which is an added bonus.
-
- Acorn provide what looks like good support for exception handler in
- the shared C library stub code. When a runtime library for a
- language wants to use functions in the shared c library it passes
- a kernel_languagedescription structure to the shared c library
- initialisation function which tell it where to find user-supplied
- functions to handle various events etc. I don't know how one
- would access these functions from the Acorn shared c library
- stubs but presumably they have included hooks to allow the user
- to have some say in what happens.
-
- --
- Andy Duplain, BT Customer Systems, Brighton, UK. duplain@rtf.bt.co.uk
- #define DISCLAIMER My views and opinions are my own, and not my company's
-