Error handling 值得介绍吗；“不正确”；避免程序崩溃的结果？

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

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

pxhour

和

Pxxmin

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

---

---

下面由@jmarkmurphy和@Charles给出的答案成功地从RPG和IBM中端的角度解决了这个问题，这正是我所追求的。

当我的计算出现错误时，我该怎么办

那些攻击用户的程序是不好的，即使是用户的错。它让用户相信程序有缺陷，然后发生的任何意外情况都会成为程序的错误；需要修理的东西。以这种方式，事情可能真的失控，导致服务台呼叫普通事件，这些事件看起来有点奇怪，即使结果实际上是正确的

一个选项是验证用户输入以防止计算错误，但是如果不能真正防止所有错误，您该怎么办。在我们的世界里，其中一种情况就是开发票。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;

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

---

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

对于

监视器

块，有两个用例

预期误差

意外错误

对于预期的错误，在某些情况下，用接受的值替换错误或无效数据是一种有效的解决方案。诀窍在于知道哪些情况。答案是你的生意人需要帮助决定的。取决于程序正在执行的操作以及有问题的数据

例如，给定某种类型的内部销售报告，您可能会有如下内容：

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为*0时，业务人员并不关心技术平均销售额是未定义的。他们只想在报告上出现一个零。他们也知道页面上的空间很小，如果数字都是9，实际值可能会更大

在这个

监视器

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

对于监视器块通过

ON-ERROR

和

*ALL

或未指定错误代码捕捉到的意外情况，我希望看到对问题进行某种记录，然后跳过问题记录或清除关闭，具体取决于程序首先执行的操作

您的代码似乎期望出现某些错误，但没有明确定义它愿意处理的错误代码这是一种懒惰的做法，不是一种好的做法。

就您对这些预期错误的处理是否有效的问题而言，只有您和您的用户可以决定

---

您可能想看看第7章——IBM红皮书的异常和错误处理

您似乎理解得很好。事情（显然）正如你所描述的那样。你到底有什么问题？看起来你真的想知道一些好的方法来克服你所看到的。顺便说一句，

Bctime

null是否可以？请重新阅读问题。我的问题不是监视器块如何工作。这就是为什么他们会这样写。如果有人看到用这种方式抑制错误的任何理由，请解释。

…它有什么帮助？

它有助于

…防止程序崩溃。

。以及

…从长远来看，它有什么帮助？计算值是否会错误并导致错误的业务数据？

（1）防止崩溃，（2）错误的结果和（3）wr