|
>>I only have one return from a procedure, with few exceptions, I just call >>the subroutine exitProcedure. Which contains any cleanup code (condition >>handler, dealloc storage, etc...) and then it returns. We do it in the same way. Almost every procedure has a Return-Subroutine. If an error occurs we'll sent an escape message from this subroutine. If no error occurs we'll fill our output parameters and leave the procedure. We try to export all (or at least most) of our procedures so that they can be called from everywhere. The procedures are not longer in the same source as the caller, but they are grouped depending on their subject. There are service programs, that consist all procedures that check the item no, i.e. Item No exist, Item No active ... Birgitta -----Original Message----- From: Lim Hock-Chai [mailto:Lim.Hock-Chai@xxxxxxxxxxxxxxx] Sent: Thursday, July 28, 2005 11:46 AM To: RPG programming on the AS400 / iSeries Subject: RE: No Subroutines (was Re: Debugging many subprocedures) In order to only have one return, you'll need to setup temp variables and/or do all type of If statement to make sure it does not execute the rest of the codes. I don't see how that would be easier to maintain. Of cause, having return all over the sub-procedure is probably not a good thing either. I normally try to do that in the beginning of the sub-procedure. This way, programmer can easily identify what will/will not be processed. -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of daparnin@xxxxxxxxxxxxxx Sent: Thursday, July 28, 2005 11:21 AM To: RPG programming on the AS400 / iSeries Subject: Re: No Subroutines (was Re: Debugging many subprocedures) Having multiple RETURN's is not good practice. This was drilled into our heads back in the first year of college. It was just like using GOTO's--you just don't do it because there are other constructs to handle it. There is only one entry point into a procedure/subroutine and there should be only one exit point. Having more than one adds potential confusion and detracts from readability. It might be easier to code but it may not be easier for someone else to maintain years from now. Just my $0.02. Dave Parnin -- Nishikawa Standard Company Topeka, IN 46571 daparnin@xxxxxxxxxxxxxx "Paul Morgan" <pmorgan@jjillgrou To: rpg400-l@xxxxxxxxxxxx p.com> cc: Sent by: Subject: Re: No Subroutines (was Re: Debugging many rpg400-l-bounces@m subprocedures) idrange.com 07/28/2005 11:04 AM Please respond to RPG programming on the AS400 / iSeries Well, LEAVESR really does a branch to ENDSR so he's correct about putting the breakpoint on ENDSR. You're right about being able to use GOTO out of the subroutine. One of the benefits for using a procedure is you can only normally exit the procedure using RETURN. I don't understand Joe's problem with multiple RETURNs in a procedure. IMHO that's a good way to code a procedure. You don't end up with all sorts of conditioned code to get to the one RETURN at the end of the procedure. Paul -- Paul Morgan Senior Programmer Analyst - Retail J. Jill Group 100 Birch Pond Drive, PO Box 2009 Tilton, NH 03276-2009 Phone: (603) 266-2117 Fax: (603) 266-2333 Scott wrote > > And procedures can be misused most horribly. One of the worst offenses > > I see is procedure with a bunch of return opcodes strewn throughout it. > > At least with a subroutine you can stick a breakpoint on the ENDSR and > > know it will get there. > > Unless there's a LEAVESR. Or a GOTO. -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
