× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Adam,

OK, I admit, it's not *absolutely* clear that Error will actually leave the
procedure, but since it's a subroutine, it should be pretty easy to find and
check - it's only going to be a few lines down the code, after all!. Maybe
I'd rename it QuitWithError rather than just Error, but in my procedures, an
Error subroutine always leaves the procedure, rather than just 'signalling'
the error. But of course that's just *my* code.

The reason I used this technique is because it makes for the simplest
retrofit to existing code which is a series of the following:

IF NOT Procedure();
RETURN *OFF;
ENDIF;

I understood (possibly incorrectly) that this was basically what David's
code consisted of, so I figured that a quick retrofit would be to replace
all instances of RETURN *OFF; with EXSR ERROR; and add the Error subroutine
at the end.

And of course this style *does* allow you to add Calculate-specific error
processing...

Rory

On Tue, Nov 25, 2008 at 10:04 AM, Adam Glauser <adamglauser@xxxxxxxxxxxx>wrote:

Rory Hewitt wrote:
> I'd say keep it as separate IF/ENDIF clauses,
with error checking at every stage. *Much* easier to debug and the extra
code is self-documenting. To expand my earlier example:

D AllWorksFine C '1'
D Oops C '0'

if not Control();
dsply 'Control failure!';
exsr error;
endif;
if not Extract();
dsply 'Extract failure!';
exsr error;
endif;
...

Return AllWorksFine;

begsr error;
...error processing...
return Oops;
endsr;

It is less obvious to me that this code does not execute Extract() when
Control() fails than the short-circuit expression version. In the case
above, you need an extra piece of information: the error subroutine
contains a return statement.

I also disagree with Vern that
> Return Control () AND Extract () AND Calculate () AND Output();

is an example of "obfuscatory style". I do however agree that the
compound if structures are more flexible for future maintenance. For
example, suppose the new requirement means adding some special error
handling code that only takes place when Calculate() fails.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.