太多异常导致错误5635？ （一个实际的Stack Overflow！）

Question

我遇到了ABL异常处理问题。如果看起来好像提出太多异常会导致错误5635？如果为真，那么异常捕获不会完全有用。

有没有人见过这个？

有没有人知道如何绕过它，没有回到旧式ABL代码而没有异常处理？

这是（部分）我的实际代码。很多奇怪的外部调用，但它是我们在这里讨论的异常检查：

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.

这是我运行时遇到的错误，大多数archead记录都会导致异常：

SYSTEM ERROR: -s exceeded. Raising STOP condition and attempting to write stack
trace to file 'procore'. Consider increasing -s startup parameter. (5635)

代码可以正常工作，有一两个例外;只有当它们中有很多（数百？）-s设置为150时它才会失败，这对我来说似乎没问题。

Answer 1

如果有不定式循环，则会出现

-s错误。

例如：

run a.

procedure a:
  run b.
end.

procedure b:
  run a.
end.

这可能是file_status函数，process_one或日志过程中的问题。

Answer 2

令人遗憾的是 - 直到我能得到一个更确定的答案 - 确实实际上显示你可以捕获的例外数量有一个上限。

以下是重现问题的最短代码：

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.

对我而言，当v-i = 4583时，这个错误始终会出现上述错误。如果我的例外使用了错误号，即undo, throw new progress.lang.apperror ("error message", 1234).，则该号码为2293。

缺少代码的复杂性，以及您获得的迭代次数取决于错误对象的复杂性，这使我相信它是导致溢出的错误对象。换句话说，每次迭代都不会清除e。

这是否是我的Openedge（10.2B）中的错误，这肯定是我将来需要解决的问题。

---

编辑：一旦你知道，解决方法就会变得非常明显。错误对象的范围限定在封闭块中，因此如果迭代，则不要对块使用catch：

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-MANAGER文档以获取更多信息。