Error Trapping
Since subroutines written in BASIC have their own execution environment, they do not share the error status conditions or error trapping of the calling program. Thus if an ASB error aborts the execution of the subroutine, causing it to end, it will still return to the calling program, which will have no idea that the error occurred in the subroutine. Thus, it is nearly essential that you implement an ON ERROR GOTO in the subroutine, as well as some means of passing error conditions back to the calling program (such as with a "STATUS" parameter in the subroutine parameter list.) If you aren’t going to pass a status parameter back to the calling program, it may be best to use MX_EXIT to abort to the dot prompt.
If you don’t trap errors within your subroutine and an error occurs, the standard ASB error message will be printed and the subroutine will return to the caller. However, since this is very likely to go unnoticed by the user, A-Shell will delay for a few seconds after displaying the error message, to give you at least some chance of being able to diagnose the condition.
You can force the ^C condition to be passed back to the calling program using:
xcall ASFLAG, AF_SETCTRLC ! (128) set ^C on return from sbx
