From: "nicholasmabry@..." Date: 2008-06-14T10:39:23+09:00 Subject: Re: raise and rescue On Jun 13, 6:25 pm, "Michael W. Ryder" <_mwry...@worldnet.att.net> wrote: > Maybe I am missing the point here but it doesn't appear that it would do > what I have been doing for over 20 years with Business Basic.  There I > enter a line saying SETERR 9200 at the beginning of the program and the > program automatically goes to that line when an error occurs anywhere in > the program.  From there I can display a message saying what is wrong > and the operator can fix the problem and continue with the program or > abort the program. That's true, and one of the trade-offs inherent to switching error handling from a GOTO control structure to a scoped control structure (such as bounded exception handling). The disadvantage is, as you've explained, that each problem area must be contained within its own error handling scope. The overwhelming advantage is that by catching errors as close to their occurrence as possible, it becomes much easier to identify just what went wrong, or pass the responsibility up to the next thing that can. Exceptions were invented to help programmers manage the complexity of handling errors. > Your example seems to require that I call a method anytime I run into a > problem.  This would seem to require that each possible problem area be > surrounded by a while loop much like I have done in C. It is possible to catch all (most) exceptions by placing your entire program in a begin-rescue block, and the rescue procedure would approximate what happens in the BASIC interrupt method. But if you do that, the disadvantage to the BASIC approach might become clear as you try to recover from the error. You'll have to know where to continue execution, as well as make sure that the rest of the application is in a similar state as it was before the error interrupted it. For a good description of the topic, check this out: http://stevemcconnell.com/ccgoto.htm I hope this helps, and good luck with your project!