操作中的印刷错误可能会导致意外结果。例如，如果旨在使用 += 将数字与变量相加，但写为 =+，操作仍然有效。但是，它不会执行加法，而是重新初始化变量。

示例 1 以下代码旨在将一个数字与变量 numberOne 相加。但是，使用 =+ 运算符实际上会将变量重新初始化为 1。

uint numberOne = 1;

function alwaysOne() public {
    numberOne =+ 1;
}

对外部合约的调用可能会失败，如果未正确处理失败，可能会导致调用合约内部出现拒绝服务。这可能会使合约无法进一步使用。

当在循环语句内执行外部调用时，这一点尤其重要，处理支付时更是如此，在这种情况下，通常最好让用户提取资金，而不是向他们推送资金。

示例 1：以下代码使用 for 循环语句，通过使用 send 外部调用向所有涉及的地址退款。

function refundAll() public {
    for(uint x; x < refundAddresses.length; x++) {
        require(refundAddresses[x].send(refunds[refundAddresses[x]]));
    }
}

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中，很容易发现两个令人怀疑的假设：“一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。”因此当程序员忽略条件时，这其实就表明了他们是基于上述假设进行的操作。

例 1：下列摘录的代码会忽略 CICS 事务期间可能发生的错误情况。

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

如果事务因为此错误情况而失败，程序会继续执行，就像什么都没有发生一样。程序不会记录任何有关这一特殊情况的依据，因而事后再查找这一异常就可能很困难。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中，很容易发现两个令人怀疑的假设：“一是这个方法调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。”因此当程序员忽略异常时，这其实就表明了他们是基于上述假设进行的操作。

例 1：下面摘录的代码会忽略一个由 doExchange() 抛出的罕见异常。

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

如果抛出 RareException 异常，程序会继续执行，就像什么都没有发生一样。程序不会记录任何有关这一特殊情况的依据，因而事后再查找这一异常就可能很困难。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中，很容易发现两个令人怀疑的假设：“一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。”因此当程序员忽略异常时，这其实就表明了他们是基于上述假设进行的操作。

例 1：下列代码忽略了在执行插入指令时可能抛出的一些异常。

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

由于该表不存在、未提供所需值或一些其他的原因，运行程序时可能会抛出异常。如果运行失败，我们就无法知道原因，因为该程序不会报告该失败或记录发生了哪种类型的失败。

多个 catch 块看上去繁琐，但使用一个“简约”的 catch 块捕获高级别的异常类（如 Exception），可能会混淆那些需要特殊处理的异常，或是捕获了不应在程序中这一点捕获的异常。本质上，捕获范围过大的异常与“Java 分类定义异常”这一目的是相违背的，随着程序的增加而抛出新异常时，这种做法会十分危险。而新发生的异常类型也不会被注意到。

示例：以下代码使用了同一方式来处理三种不同的异常类型。

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

其实，与其这样，还不如使用一个单独的 catch 块来处理这三种异常，如下所示：

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

但是如果修改 doExchange()，以抛出需要以某种不同的方式处理的新异常类型，则范围过大的 catch 块会阻止编译器指出这一情况（有新的异常抛出）。此外，新 catch 块也将处理那些来自于 RuntimeException 的异常，比如 ClassCastException 和 NullPointerException，而这些异常的发生是不在程序员的计划之内的。

声明一种可以抛出 Exception 或 Throwable 异常的方法，从而使调用者很难处理和修复发生的错误。Java 异常机制的设置是：调用者可以方便地预计有可能发生的各种错误，并为每种异常情况编写处理代码。同时声明：一个方法抛出一个过于笼统的异常违反该系统。

示例：以下方法抛出了三种类型的异常。

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

这样写看上去会显得更加紧凑

public void doExchange()
  throws Exception {
  ...
}

这样做会防碍调用者理解和处理所发生的异常。此外，如果 doExchange() 因为变更了代码，而引入了一个需要不同于之前异常处理方式的新型异常，则不能使用简单的方式来处理该要求。