Page 1 of 1

Library programs that don't return to the calling program

Posted: Fri Aug 07, 2009 9:54 am
by Susan Smith
Recently, I started a thread about error-handling routines in libraries. This is related:

I am putting more and more entire programs into libraries so they can be called from multiple places. Those programs either have built-in error-handling routines or else they call ANOTHER library to do that. Most of my error-handling routines have options to exit the program and chain back to the menu when an error can't be successfully handled any other way.

This is the scenario:
    a. I call a library (which may call another library, which calls another, etc.)
    b. I get an error in one of those nested libraries
    c. I chain directly out to a menu instead of retracing my steps backwards (via the FNEND which in my mind I equate to a RETURN in a GOSUB)

Are there stack issues or other ramifications to watch out for? I'm envisioning this sort of like nested gosubs that ultimately use a GOTO to exit, rather than navigating the RETURN statements by keeping track of the error information and handling it when I finally arrive back to my starting point.

It's sure a lot easier to handle an error in a nested library by being able to ABORT back to the menu. But is there a downside?

-- Susan

Posted: Fri Aug 07, 2009 12:51 pm
by Gabriel
I bet the CHAIN command clears the current stacks before chaining to the target program. So if you're in a function, or in a for loop, or a subroutine, the CHAIN command probably causes BR to forget all that stuff. So you're probably ok.

But you can test it easily enough. Just do a status stacks when you get to the calling program.

In fact, I just tried it (one of my programs chains out of a library) and all the stacks were cleared, just as if I had cleared the program by hand and loaded the new one.


Posted: Fri Aug 07, 2009 12:57 pm
by Susan Smith
Thanks Gabriel. I never thought of checking the status of the stacks. (duh...)

I'm glad the stacks are automatically cleared because with nested libraries, I just can't think from a high enough perspective to anticipate every possible avenue my programs might ultimately take (like water running through stones!) and try to code from that trajectory. Sometimes you just have to find the 'YOU ARE HERE" sticker on the shopping mall directory and navigate from there, rather than retracing the breadcrumb trail back to the beginning.

-- Susan