I remember also for me, when I was first learning CATCH, that it took a long time for me to understand how and where it was "branching" to. Once I understood it, though, its behavior seemed very intuitive and obvious, so I could not understand why I struggled with it for so many hours when I first learned it. The straightforward behavior rule is: No matter where the error is triggered, once the error passes the execution to the code in the CATCH statement, the execution proceeds forward from that line, executing first the "catch block" error handler and then reexecuting all lines that follow the catch block up to and including the line that triggered the error that is being handled. In short, execution jumps from the error line to the CATCH line and then flows according to normal rules. The only difference from the first pass through CATCH is that 'Error_status' is no longer equal to zero this second time through. If you do not want the lines immediately after the catch block error handler to execute, then the error handler will have to make the line of execution "jump" to a different "entry point" in your code. A GOTO statement will allow that, although many expert programmers say that the GOTO statement is a dangerous and code-share-unfriendly tool. There are other options, of course. For example, the error handler could have a conditional flag that is checked by the next line after the error handler, e.g. if error_handled eq 0 then begin ; Do the routine behavior ; ... endif else begin ; Pick up here after an error is handled ; ... The best approach, however, is to get your error handler as close to the possible error line as possible, I think. If you suspect that a file I/O action, for example, is the most likely to trigger a specific error, insert a CATCH block right above that file I/O codeline. James Jones ITT Technical Support