ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (06/03/91)
I'm currently adding error handling code to my Windows program (an astronomy simulation/prediction/graphing program, for what it's worth). I've added code to handle the obvious problems, for example: cannot find file printer hasn't been specified printer won't do graphics But I'm wondering how to handle some non-obvious things. So heres' a list of questions: 1. Are Catch() and Throw() reasonable to use when one of your program's commands has failed and you want to go back to the main event loop? For example, your main event loop calls a routine that calls a routine that calls a routine that ,..., calls a routine that fails and you just want to quit what you're doing and let the user make another menu selection. In other words, are Catch() and Throw() reasonable to use & safe? What are the non-obvious pitfalls??? 2. I am dreading having to check the error codes from every single Windows function that my (30,000 line) program calls. Are there alternatives that will still catch every failure? For example, is there a mechanism that would "call the specified function if failure X occurrs". For example, my program is graphically intensive. It would be way cool to give Windows the address of a function to call whenever a request for a handle to a new gdi object failed... By the way, I have Petzold, Prog. Ref. and Guide to Programming. I looked in vain for coverage of error handling (beyond testing the results of evry function call). If I missed anything, just send me a page number! Terrell
cadsi@ccad.uiowa.edu (CADSI) (06/05/91)
From article <1991Jun3.025142.4227@mnemosyne.cs.du.edu>, by ebergman@isis.cs.du.edu (Eric Bergman-Terrell): > > [ stuff deleted ] > 1. Are Catch() and Throw() reasonable to use when one of your program's > commands has failed and you want to go back to the main event loop? > > For example, your main event loop calls a routine that calls a > routine that calls a routine that ,..., calls a routine that fails > and you just want to quit what you're doing and let the user make > another menu selection. > > In other words, are Catch() and Throw() reasonable to use & safe? > What are the non-obvious pitfalls??? I use Catch and Throw in order to catch math (matherr.c) problems. It works for me. They have recovered from some VERY deep recursions and I Still have no problems. I Do personally hate the way they declare the buffer. In the Catch call you're supposed pass a CATCHBUF pointer. Thing is, a CATCHBUF is already a pointer since its just an array for register variables. Thus, if you try Catch(&catchbuf), MS C compiler complains about superfluous & on array. You'd think MS would have handled this a little better. > If you are planning to jump back to a spot where a Menu was popped up, it probably won't work, since the menu would no longer be popped up. However, If you put the Catch call at the top of a message "switch", it works ok. > 2. I am dreading having to check the error codes from every single > Windows function that my (30,000 line) program calls. Are there > alternatives that will still catch every failure? For example, > is there a mechanism that would "call the specified function if > failure X occurrs". > > For example, my program is graphically intensive. It would be way > cool to give Windows the address of a function to call whenever a > request for a handle to a new gdi object failed... You need to redefine the 'new' operator (use C++). |----------------------------------------------------------------------------| |Tom Hite | The views expressed by me | |Manager, Product development | are mine, not necessarily | |CADSI (Computer Aided Design Software Inc. | the views of CADSI. | |----------------------------------------------------------------------------|