Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.software-eng
Subject: Re: error handling techniques?
Message-ID: <957@mwtech.UUCP>
Date: 14 Nov 90 18:08:09 GMT
References: <1990Nov2.205831.23696@elroy.jpl.nasa.gov> <1990Nov3.153643.26368@clear.com> <234@smds.UUCP>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 30

In article <234@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
>In article <1990Nov3.153643.26368@clear.com>, rmartin@clear.com (Bob Martin) writes:
>> In article <1990Nov2.205831.23696@elroy.jpl.nasa.gov> alan@cogswell.Jpl.Nasa.Gov (Alan S. Mazer) writes:
>> >I'm interested in what approaches people use for error handling, particularly
>> >in general purpose function libraries and large software systems.  If someone
>
>	[See the referenced article, which is commendably well written.]
>
>In our key product, which we assume is mission critical for our users,
>we take the strong view that any trapped error is a fatal error.  We try
>to arrange that the software fails gracefully and that it produces as
>much information about the error as possible. [...]

I share this view. But I think it is an oversight (which also made it
into ANSI-C), that there is no (portable) way to fail gracefully if the
stack runs into the heap. (You can detect if the heap would run into the
stack, as malloc and friends fail in this case, but not the other
way round.)

Any solutions?

>I would like to see more contributions on this topic.

You've just read mine :-)

P.S.: If you supply `Followup-To:'-lines, please double check for typos.
      "inews" just complained about the missing news group comp.softwar-eng
       and didn't fail in the most "graceful" way :-/.                ^^
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83