dwpst@unix.cis.pitt.edu (Douglas W Philips) (01/17/91)
In article <9101161407.AA29459@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: >I used to use a tagged error handling mechanism semantically similar >to the one Bill Bouma suggests. I found that there are a lot of cases >where I need to be able to catch any error at all (for instance, in >order to release resources allocated at the CATCH level). > >In some instances, the "tagged" CATCH/THROW is indeed easier to use, >but unless you further complicate it by adding a "wildcard" tag, >it is not as powerful as the "simple" CATCH/THROW . I think you are confusing two different ideas with the same name. A catcher *should* be something that will do something with a particular error. Releasing memory, in the scheme you describe above, has nothing to do with any particular error, and everything to do with an unusual flow of control. What you really want here is some kind of UNWIND-PROTECTION so that if the current word is going to be blasted off the return stack by a catch, you want some code to execute first. I think this is what Lisp/Common Lisp does. In any event, stopping a stack unwind (CATCH) at a particular point to deal with the error raised (THROW) is not the same thing as "BTW: If you don't return normally, please run this code on the way out. Thanks." which is an unwind protection. If you overload both onto the same mechanism you end up with UGLY code. I would say UGLY because of an improper factoring though. -Doug