APL*PLUS II Error trapping 
Author Message
 APL*PLUS II Error trapping

I apologise for raising a real-world issue in such an esoteric
newsgroup.  I hope that someone will be able to help me or point me to
another forum where help might be available (something like the
ms.public ngs)   :)

My problem is as follows:
Reading a file of insurance policy data,  and doing various calculations
on each record.  If I encounter an error I would like to do some error
reporting and then continue with the next record.  My structure is:
.
.
.
[100]quadELX <- 'ELXHANDLER'
[101]lamp del{*:ERRORREP diamond ->LOOP}
[102]LOOP: until end of file
[103]    READ_RECORD  (down 2 levels)
[104]    MAIN_CALC    (multilevel tree)
[105]    ->LOOP

where ERRORREP puts info including quadDM and quadSI to a file.

This construct works,  but doesn't give me exactly what I want.  The
error routine is performed at the top level and so quadDM tells me I
have an error in MAIN[104] rather than where the actual error occurred.

If I extend the scope of the error handler (i.e. put a down arrow before
the * in the public comment) then I would get the diagnostics that I
want,  but then I'm stuck down at the lower levels,  whereas I need to
get back to the top level to be able to branch to LOOP.

Any help would be appreciated.

willem van der eijk



Fri, 23 Mar 2001 03:00:00 GMT  
 APL*PLUS II Error trapping

Quote:
>My problem is as follows:
>Reading a file of insurance policy data,  and doing various calculations
>on each record.  If I encounter an error I would like to do some error
>reporting and then continue with the next record.  My structure is:
>but then I'm stuck down at the lower levels,  whereas I need to
>get back to the top level to be able to branch to LOOP.

There is a routine called SHUTDOWN that APL2000 distributes with the
runtime versions of APL*PLUS II. It will take you up the stack until it
comes across a special statement label, usually called "errorbranch." Then
you can add []DM to a file and continue processing.

Don (at panix com).



Sat, 24 Mar 2001 03:00:00 GMT  
 APL*PLUS II Error trapping
Don,

What I usually do in these situations (where garbage input fouls some routine)
is to have each susceptible function produce an explicit result that will let
the calling function know that an error has been encountered. Of course, the
original function should utilize quad-ELX to perform whatever error processing
deemed necessary to identify the bad data and/or write information to a
diagnostic file or report. When the calling function receives the explicit
result of the processing function and sees that it is an error condition, it
can then safely assume that the bad data has been flagged and can continue on
with the next record. I have found that using return codes to climb up the
stack is a simple and self documenting method for handling of bad data.

Mike DeAngelo

Quote:


> >My problem is as follows:
> >Reading a file of insurance policy data,  and doing various calculations
> >on each record.  If I encounter an error I would like to do some error
> >reporting and then continue with the next record.  My structure is:

> >but then I'm stuck down at the lower levels,  whereas I need to
> >get back to the top level to be able to branch to LOOP.

> There is a routine called SHUTDOWN that APL2000 distributes with the
> runtime versions of APL*PLUS II. It will take you up the stack until it
> comes across a special statement label, usually called "errorbranch." Then
> you can add []DM to a file and continue processing.

> Don (at panix com).



Sun, 25 Mar 2001 03:00:00 GMT  
 APL*PLUS II Error trapping
Quote:

> Don,

> What I usually do in these situations (where garbage input fouls some routine)
> is to have each susceptible function produce an explicit result that will let
> the calling function know that an error has been encountered. Of course, the
> original function should utilize quad-ELX to perform whatever error processing
> deemed necessary to identify the bad data and/or write information to a
> diagnostic file or report. When the calling function receives the explicit
> result of the processing function and sees that it is an error condition, it
> can then safely assume that the bad data has been flagged and can continue on
> with the next record. I have found that using return codes to climb up the
> stack is a simple and self documenting method for handling of bad data.

> Mike DeAngelo



Thanks for the input so far.
Mike.....this can work.  However,  if the function tree is complex the
need to put if statements after each function call becomes very time
consuming - both to program and for run-time.  As I'm already looking
at  13 hour run times for one of my input files I'm not willing to add
in code that will have the effect ofincreasing that dramatically.  The
beauty of the ELXHANDLER is that it is only activated when an error
occurs.

Don..... is the RT version freely available?

Any other suggestions,  anyone???

willem van der eijk

- Show quoted text -

Quote:


> > >My problem is as follows:
> > >Reading a file of insurance policy data,  and doing various calculations
> > >on each record.  If I encounter an error I would like to do some error
> > >reporting and then continue with the next record.  My structure is:

> > >but then I'm stuck down at the lower levels,  whereas I need to
> > >get back to the top level to be able to branch to LOOP.

> > There is a routine called SHUTDOWN that APL2000 distributes with the
> > runtime versions of APL*PLUS II. It will take you up the stack until it
> > comes across a special statement label, usually called "errorbranch." Then
> > you can add []DM to a file and continue processing.

> > Don (at panix com).



Sun, 25 Mar 2001 03:00:00 GMT  
 APL*PLUS II Error trapping
If the immediate goal is to determine the error in MAIN_CALC, I would
modify that function:

[1] Localize []ELX
[2] Set []ELX to be '[]ERROR []DM'

which will build a complete list of the entire program stack, which will then
appear in the ERRORREP file...

This of course does not address the question of suspended actions: files
that are normally opened and closed by MAIN_CALC, but which remain
open because of the error, for example.  Not serious in most cases, because
seeing the error, leads to fixing the error, leads to clean resource usage.

.. to your first sentence.

Your question is quite germane to this group.
comp.lang.apl only seems esoteric because that's what gets posted.  A lot of
practical questions tend to go to APL vendors, leaving the general stuff for
here. I would prefer for people to also post here, as the vendors seem to
be quite parsimomious with what "answered questions" they make available,
on websites, or in documentation.


Quote:

>I apologise for raising a real-world issue in such an esoteric
>newsgroup.  I hope that someone will be able to help me or point me to
>another forum where help might be available (something like the
>ms.public ngs)   :)

>My problem is as follows:
>Reading a file of insurance policy data,  and doing various calculations
>on each record.  If I encounter an error I would like to do some error
>reporting and then continue with the next record.  My structure is:
>where ERRORREP puts info including quadDM and quadSI to a file.

>This construct works,  but doesn't give me exactly what I want.  The
>error routine is performed at the top level and so quadDM tells me I
>have an error in MAIN[104] rather than where the actual error occurred.

>If I extend the scope of the error handler (i.e. put a down arrow before
>the * in the public comment) then I would get the diagnostics that I
>want,  but then I'm stuck down at the lower levels,  whereas I need to
>get back to the top level to be able to branch to LOOP.

--
|\/| Randy A MacDonald       |"We ARE the weirdos, mister!"

     BSc(Math) UNBF '83      | APL: If you can say it, it's done.

     I use Real J            | Also http://www.godin.com/godin/
------------------------------------------------<-NTP>----{ gnat }-


Sun, 25 Mar 2001 03:00:00 GMT  
 APL*PLUS II Error trapping

Quote:
>Don..... is the RT version freely available?

It wasn't in older versions. I don't know about the new version 6, as I
have not upgraded to it (there is a reason, but that isn't what you are
asking here). I see no reason why SHUTDOWN can't be passed around, as it
has nothing to do with the runtime interpretter. I will e-mail it to you.

Don (at panix com).



Mon, 26 Mar 2001 03:00:00 GMT  
 APL*PLUS II Error trapping
 Have a look at function GOTO in ws UTILITY. It does what you need
i.e. pop the stack and branch.

On Mon, 5 Oct 1998 16:19:46, Willem van der Eijk

Quote:

>  If I encounter an error I would like to do some error
> reporting and then continue with the next record.



Sat, 31 Mar 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. XP and APL font for APL-PLUS II?

2. Paradox and APL*PLUS II (Or APL+WIN) and Memo Fields

3. Need Assistance to Use APL*Plus II/386 Under WINNT

4. APLBUG : MANUGISTICS demos APL PLUS II release 5 : Software Drwng

5. STSC APL*PLUS II Version 4

6. STSC APL*PLUS for Mac II: any patches?

7. APL PLUS II V5.2 Graphic Init

8. Converting - APL PLUS II 386 - WinAPL

9. APL*PLUS II/386 running on Windows 95

10. APL*PLUS II runtime wanted

11. APL*PLUS II under NT4.0 - continued

12. APL*PLUS II under NT4.0

 

 
Powered by phpBB® Forum Software