From your error handler, you can do several things. I think that CANCEL will do the same as quit except that I think it will bypass your on shutdown procedure. This is probably what you are seeing. If you want your error handler to close down the application, you should issue QUIT instead of CANCEL and your on shutdown procedure should take care of cleanup.

If you want the error handler to continue with the next line as if no error had occurred, you can return .t. from the error handler. This will probably cause some further problems down the line and is not really a good idea.

If you want the process to abort and return to the main procedure (basically return to the read events), in you error handler you can RETURN TO MAIN. This may also cause problems by not cleaning up after the procedure that generated the error but may be preferrable to throwing the user out.

If you want to allow the process to retry, when the user selects retry your error handler can issue RETRY. If the error persists, it will again be caught by your error handler until it succeeds or you abort.

HTH