Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!polyslo!ttwang From: ttwang@polyslo.CalPoly.EDU (Thomas Wang) Newsgroups: comp.lang.c++ Subject: Re: EC++.TUTORIAL Message-ID: <1989Oct25.212837.19883@polyslo.CalPoly.EDU> Date: 25 Oct 89 21:28:37 GMT References: <208@eiffel.UUCP> Reply-To: ttwang@polyslo.CalPoly.EDU (Thomas Wang) Distribution: comp.lang.c++, comp.object Organization: Cal Poly State University -- San Luis Obispo Lines: 54 The EC++ manual describes the exception handling mechanism as implemented by setjmp() and longjmp(). I had considered implementing such a mechanism a while ago, and the response from USENET unix gurus are that setjmp() and longjmp() are not portable. They are not even guaranteed to work in future compilers on traditional CISC machines. The problem is that longjmp() will restore the value of register variables, and keep the value of memory variables unchanged. As the 'register' declaration is only a hint to the compiler, all variables declared as 'register' will have undefined values after a longjmp(). If one uses longjmp(), then all local variables must be declared 'volatile'. This will have some performance impact. Also using longjmp() will leave the destructors not called. The assumption made by EC++ is that people will be using Boehm's garbage collector, so there will not be any destructors to call. I think generally this will not be true. Exception handling is useful independent of any garbage collector used. There are other garbage collection schemes that requires destructors to be called (such as my MM garbage collector). A way of using longjmp() but at the same time call all the destructors is presented in 1988 USENIX C++ Conference "Excepton Handling Without Language Extensions". Perhaps EC++ can use this scheme to improve the exception handling implementation. The long term solution I believe not to be any variant of setjmp()/longjmp() implementation, but one which is build into the language. I likes the idea that every function must have a default exception handler, and zero or more user defined exception handlers. This way, the program can directly branch to the exception handler without stack manipulation when an error occurred. I think there is two appropriate ways an exception handler can propagate the error down the exception handler chain. The exception handler can directly modify the return address on the stack to point to the next exception handler. This option requires the address of the next exception handler passed as a hidden parameter. A second option is just set an error variable, and return. The caller then test the error variable, and branch to its own exception handler. Both of these schemes require a small constant overhead. This disadvantage is offset by the ability to use register variables and non-volatile variables freely, not to mention the portability issues. The constant overhead of the first approach is the time to push the address of the exception handler on stack. The constant overhead of the second approach is the time to test the error variable and branch to exception handler. -Thomas Wang (Programming without exception handling is like driving without breaks!) ttwang@polyslo.edu