Path: utzoo!mnetor!uunet!tektronix!zeus!teklds!daniels From: daniels@teklds.TEK.COM (Scott Daniels) Newsgroups: comp.lang.c++ Subject: Re: Proposal for Exceptions for C++ Message-ID: <2988@teklds.TEK.COM> Date: 31 Mar 88 22:03:17 GMT References: <8180006@eecs.nwu.edu> <2229@phoenix.Princeton.EDU> Reply-To: daniels@teklds.UUCP (Scott Daniels) Organization: Tektronix, Inc., Beaverton, OR. Lines: 42 In article <2229@phoenix.Princeton.EDU> lgy@pupthy2.PRINCETON.EDU (Larry Yaffe) writes: >... As far as I can tell, this proposal for exception handling >(as well as exception handling in many other languages) fails to allow >a very basic form of exception handling that I regard as essential: >the ability for an exception handler to return control to the point >at which the exception was (first) raised and NOT disturb the normal flow >of control.... The problem with this approach is that it dictates a substantial change in the C language implementation requirements. Without this capability, all C variable accesses may be reached either by a global access (typically an absolute address), or as addresses relative to a stack pointer (for auto variables). With this requirement, the "catch statement" must be able to access the locals for the function in which it is executing, while still maintaining a stack depth that allows returning to the original function. Note that this problem exists by implication in the stated design since the default handler "prints the stack"... If the stack is abandoned (as an alternate return mechanism might reasonably do), there is nothing left to print. Managing a stack that happens from this code would be a nightmare: main(argc, argv) int argc; char **argv; { something() catch { foo( mumble(), fumble() ) catch { printf("Oops: %s caught in catch\n", argv[0]); if( random() > 0.5 ) resume_original; if( random() > 0.5 ) resume_here; printf( "catch in catch completed.\n" ); } printf( "catch completed.\n" ); } printf( "main completed.\n" ); } -Scott Daniels daniels@teklds.UUCP