jima@hplsla.HP.COM ( Jim Adcock) (01/23/88)
Has anyone figured out a good way to do "try/recover-type" schemes in C++ without hacking up the language? IE no fair hacking up cfront, nor adding another preprocessor, nor postprocessor, nor adding new keywords. So, is there anyway to implement try/recover using some kind of classes, considering the process itself to be an object, or something like that? Or is it necessary to extend the definition of the language to include "try/recover"-type capabilities? Any other bright ideas on how to recover from errors within a body of software [that may include c++ functions]? [The big problem I see with try/recover schemes in C++ is that when you get a failure in a member function, then you presumably bounce out, taking an extrodinary exit from the member function, in order to get to the surrounding context provided by the recover statement. So how do you get the routine which took the extrodinary exit to correctly destroy its local objects when it bounces to the surrounding context?]
mjy@sdti.UUCP (Michael J. Young) (01/28/88)
In article <6590011@hplsla.HP.COM> jima@hplsla.HP.COM ( Jim Adcock) writes: >Has anyone figured out a good way to do "try/recover-type" schemes in C++ >without hacking up the language? >... >Any other bright ideas on how to recover from errors within a body of >software [that may include c++ functions]? We've been dealing with this very problem on our project, and have come up with what I think is a fairly elegant and generic error handling package which requires no changes to the language itself. William Miller, who designed and implemented the package, has submitted an article to Computer Language on the subject. It is currently being reviewed for possible publication in the May issue. The design not only ensures that destructors will be called when stack frames are discarded, but also implements the best features of Ada exception handlers and PL/I on-units while avoiding some of the disadvantages of each. I won't attempt to go into a lengthy description of the design, since I couldn't do it justice. The article (I've read a draft) provides plenty of detail. -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779