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

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.

Continue reading...