Path: utzoo!attcan!uunet!husc6!rutgers!ucsd!ucbvax!ernie.Berkeley.EDU!jas
From: jas@ernie.Berkeley.EDU (Jim Shankland)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <27681@ucbvax.BERKELEY.EDU>
Date: 23 Jan 89 03:41:20 GMT
References: <25@torsqnt.UUCP> <8867@bloom-beacon.MIT.EDU> <7222@polyslo.CalPoly.EDU> <8812@alice.UUCP> <9480@smoke.BRL.MIL>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jas@ernie.Berkeley.EDU.UUCP (Jim Shankland)
Organization: University of California, Berkeley
Lines: 19

In article <9480@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>Really, setjmp/longjmp is just a groady "goto" and should be
>avoided for the same reasons as the ordinary "goto".  In fact
>it is even more violent than an ordinary "goto", which is why
>it has to be more loosely constrained.  I don't think I've
>even seen a case in which setjmp/longjmp was the best way to
>design code, let alone essential.

You can build a pretty nice exception mechanism on top of setjmp/longjmp.
Having some functions (memory allocation is a good example) raise
exceptions rather than returning an error status can unclutter your
code and give your weary typing fingers a rest.  (Not as much as not
checking error statuses at all, but we all know better than that --
don't we?)

Jim Shankland
jas@ernie.berkeley.edu

"I've been walking in a river all my life, and now my feet are wet"