Too many exceptions causes error 5635? (An actual Stack Overflow!) - openedge

Question

I've got a problem with ABL exception handling. If looks as if raising too many exceptions gets you an error 5635? Which would make exception trapping not entirely useful, if true.
Has anyone else seen this?
Does anyone know of a way around it, short of going back to old-style ABL code without exception handling?
Here is (some of) my actual code. Lots of weird external calls but it's the exception checking we are talking about here:
for each b-archead
where b-archead.depot = ip-depot
and b-archead.o-week >= ip-startwk
and b-archead.o-week <= ip-endwk
use-index o-week
no-lock
on error undo, throw:
assign v-directory = b-archead.directory
v-invoice = b-archead.invoice
v-o-date = b-archead.o-date
v-path = arc_path(buffer b-archead)
v-success = no
v-error = "".
if not file_status(v-path) begins "Y"
then
undo, throw new progress.lang.apperror
(subst("Source file '&1' missing", v-path), 300).
run process_one (buffer b-archead, input v-path, input ip-todir).
v-success = yes.
catch e2 as progress.lang.error:
v-error = e2:getmessage(1).
run log ( 'w', v-error ).
next.
end catch.
finally:
put stream s-out unformatted
csv_char(v-directory)
',' csv_int(v-invoice)
',' csv_date(v-o-date)
',' csv_int(v-o-week)
',' csv_char(v-path)
',' csv_char(v-success)
',' csv_char(v-error)
skip.
end finally.
end.
Here is the error I get when I run it and most of the archead records result in an exception:
SYSTEM ERROR: -s exceeded. Raising STOP condition and attempting to write stack
trace to file 'procore'. Consider increasing -s startup parameter. (5635)
The code works fine with one or two exceptions; it only fails when there are a lot of them (hundreds?) -s is set to 150, which seems okay to me.

Answer 1

-s error can occur when you have an infinitive loop.
for example:
run a.
procedure a:
run b.
end.
procedure b:
run a.
end.
It could be a problem in file_status function, process_one or log procedure.

Answer 2

Regrettably -- and until I can get a more definitive answer -- it does in fact appear that there is an upper limit on the number of exceptions you can catch.
Here is the shortest code that reproduces the problem:
def var v-i as int no-undo.
do v-i = 1 to 5000 on error undo, throw:
undo, throw new progress.lang.apperror ( "error message" ).
catch e as progress.lang.apperror:
message "boo". pause 0.
end catch.
end.
For me this always falls over with the error above at the point when v-i = 4583. If my exception uses an error number, i.e. undo, throw new progress.lang.apperror ("error message", 1234)., then the number is 2293.
The lack of complexity of the failing code, plus the fact that the number of iterations you get depends on the complexity of the error object, leads me to believe that it is the error object that is causing the overflow. In other words, e is not cleared down with each iteration.
Whether or not this is a bug in my Openedge (10.2B) it's certainly something I will have to work around in future.
EDIT: the workaround turns out to be painfully obvious once you know it. The error object is scoped to the enclosing block, so don't use catch against a block if it iterates:
def var v-i as int no-undo.
do v-i = 1 to 5000 on error undo, throw:
do on error undo, throw:
undo, throw new progress.lang.apperror ( "error message" ).
catch e as progress.lang.apperror:
message "boo". pause 0.
end catch.
end.
end.

Answer 3

Log the activity to see what is actually going on - check the LOG-MANAGER docs for more info.