Question

在我的组织中，我看到很多地方已将代码放在监视器块（RPG的try..except版本）中，以防止引起算术错误的异常。例如：

Monitor;                    
  Pxxhour = Bctime/60;      
  PxxMin  = %Rem(Bctime:60);
On-Error;                   
  Pxxhour = 0;              
  PxxMin  = 0;

Pxxhour和Pxxmin是将向用户显示的屏幕字段。因此，如果操作中出现错误，则它们的值为0.虽然这可以防止程序崩溃，但它有何帮助？用户在屏幕上看到错误的值。类似地，我看到代码为给定变量赋予最高可能值，而不是允许溢出异常。虽然这会阻止程序爆炸，但从长远来看它有何帮助？计算不会有错误的值并导致错误的业务数据吗？

@jmarkmurphy和@Charles在下面给出的答案成功解决了RPG和IBM中端视角的问题，这就是我所追求的。

Answer 1

MONITOR块有两个用例...

预期错误
意外错误

对于预期的错误，在某些情况下，用可接受的值替换错误或无效的数据是有效的解决方案。诀窍是知道哪些情况。答案是您的业务人员需要帮助决定的。取决于程序正在做什么以及哪些数据存在问题。

例如，鉴于某种内部销售报告，您可能会有这样的事情：

dcl-c DIVIDE_BY_ZERO  const(00102);
dcl-c RESULT_TO_LARGE  const(00103);

monitor;
  averageSale = totalSalesAmount / numberSales;
on-error DIVIDE_BY_ZERO;
  averageSale = 0;
on-error RESULT_TO_LARGE;
  averageSale = *HIVAL;
endmon;

上述重要的是我期待两个可能的错误之一，我决定以某种方式处理它们。当numberSales为* ZERO时，业务人员并不关心技术上的averageSale是不确定的。他们只想在报告中出现零。他们也明白页面上只有这么多空间，如果数字都是9，那么实际值可能会更大。

此MONITOR块不会捕获意外错误，例如十进制数据错误。

对于监视程序阻塞通过ON-ERROR *ALL或未指定错误代码捕获的意外，我希望看到某种问题的记录，然后跳过问题记录或根据程序首先执行的操作清理关闭。

您的代码似乎期待某些错误，但没有明确定义它愿意处理的错误代码。 这是懒惰而不是一个好习惯。

至于您对这些预期错误的处理是否有效的问题...... 只有您和您的用户可以决定

您可能想看看IBM红皮书Who Knew You Could Do That with RPG IV? Modern RPG for the Modern Programmer

异常和错误处理

Answer 2

我的计算错误时该怎么办

炸毁用户的程序很糟糕，即使是用户的错误。它使用户相信程序是错误的，然后发生的任何意外事件都会成为程序的错误;有待修复的东西。事情可能会以这种方式失控，导致帮助台呼叫普通事件，即使结果实际上是正确的，也会显得有些奇怪。

一个选项是验证用户输入以防止计算错误，但是当您无法真正阻止所有这些错误时，您会怎么做。在我们的世界中，其中一种情况是开发票。 5250个屏幕的房地产有限，你不能总是把这些字段变得足够大，以容纳所有不测事件。所以需要权衡。也许你需要能够在一张发票上出售数以千计的小件物品，但你曾经拥有的最大总发票是10万美元。因此，您可以像这样调整字段大小：

dcl-s quantity        Packed(5:0);
dcl-s unitPrice       Packed(7:2);
dcl-s ammount         Packed(9:2);

所有这些都很奇怪，因为它们在磁盘上占用的空间与下一个更低的均匀精度相同。您不会销售小数量，每个字段的最大值为：

quantity = 99,999;
unitPrice = $99,999.99;
amount = $9,999,999.99;

现在您可以看到这些最大值应该可以轻松处理所有有效的发票，但它也会留下很多计算错误的可能性。如果用户键入quantity和unitPrice的最大数字，则结果数字将需要Packed（12：2）字段。这会导致溢出。在单位价格存储在发票明细中的发票中，我们可以在输入数量和单价时检查扩展量溢出时添加编辑，并发送相应的错误消息。但是，如果单位价格未存储在发票明细中，而是存储在定价表中，该怎么办？现在没有一个好的方法，如果价格改变，例如确保现有的发票都不会受到不利影响。

那么你如何处理十进制溢出或任何其他计算错误，无论是数据问题还是别的什么？如果发生错误会发生什么吹起程序不是一个好选择。另一个选项，似乎在问题中采用的一个选项是应用一些用户将很快识别的默认值是不寻常的。它将出现在报告和屏幕上。当用户看到那些过大或过小的数字时，他们就会知道返回并检查数据。

是否值得引入“不正确”的结果以避免程序崩溃？

2 个答案: