50

根据副作用的维基百科条目，引发异常构成副作用。考虑这个简单的python函数：

def foo(arg):
    if not arg:
        raise ValueError('arg cannot be None')
    else:
        return 10

调用它foo(None)总是会遇到异常。一样的输入，一样的输出。它是参照透明的。为什么这不是纯函数？

4

5 回答 5

35

只有当您观察到异常并根据它做出改变控制流的决定时，才会违反纯度。实际上抛出异常值是引用透明的——它在语义上等同于非终止或其他所谓的底值。

如果（纯）函数不是total，则它的计算结果为底部值。如何编码底部值取决于实现——它可能是一个例外；或不终止，或除以零，或其他一些故障。

考虑纯函数：

 f :: Int -> Int
 f 0 = 1
 f 1 = 2

这不是为所有输入定义的。对于某些人来说，它评估为底部。实现通过抛出异常对此进行编码。它在语义上应该等同于使用MaybeorOption类型。

现在，只有在观察底部值并根据它做出决策时才会破坏引用透明度——这可能会引入不确定性，因为可能会抛出许多不同的异常，而你不知道是哪一个。因此，出于这个原因，捕获异常是在IOHaskell 的 monad 中，而生成所谓的“不精确”异常可以纯粹地完成。

因此，引发异常本身就是一种副作用是不正确的。问题在于您是否可以基于异常值修改纯函数的行为——从而破坏引用透明度——这就是问题所在。

于 2012-05-23T12:35:27.353 回答
16

从第一行开始：

“在计算机科学中，如果一个函数或表达式除了返回一个值之外，它还修改了某些状态或与调用函数或外部世界有可观察的交互，则称其具有副作用”

它修改的状态是程序的终止。回答您关于为什么它不是纯函数的其他问题。该函数不是纯函数，因为抛出异常会终止程序，因此它具有副作用（您的程序结束）。

于 2012-05-22T13:43:39.680 回答
6

引用透明性也是用计算本身的结果替换计算（例如函数调用）的可能性，如果您的函数引发异常，您就无法做到这一点。那是因为异常不参与计算，但它们需要被捕获！

于 2012-05-22T13:43:55.103 回答
5

我意识到这是一个老问题，但这里的答案并不完全正确，恕我直言。

引用透明性是指表达式具有的属性，如果它所属的程序在表达式被其结果替换时具有完全相同的含义。应该清楚的是，抛出异常违反了引用透明性，因此会产生副作用。让我证明为什么...

我在这个例子中使用了Scala。考虑以下函数，它接受一个整数参数 ，i并向其添加一个整数值j，然后将结果作为整数返回。如果在添加两个值时发生异常，则返回值 0。唉，计算j' 的值会导致抛出异常（为简单起见，我已将j' 的初始化表达式替换为生成的异常）。

def someCalculation(i: Int): Int = {
  val j: Int = throw new RuntimeException("Something went wrong...")
  try {
    i + j
  }
  catch {
    case e: Exception => 0 // Return 0 if we catch any exception.
  }
}

好的。这有点愚蠢，但我试图用一个非常简单的案例来证明这一点。;-)

让我们在Scala REPL中定义并调用这个函数，看看我们得到了什么：

$ scala
Welcome to Scala 2.13.0 (OpenJDK 64-Bit Server VM, Java 11.0.4).
Type in expressions for evaluation. Or try :help.

scala> :paste
// Entering paste mode (ctrl-D to finish)

def someCalculation(i: Int): Int = {
  val j: Int = throw new RuntimeException("Something went wrong...")
  try {
    i + j
  }
  catch {
    case e: Exception => 0 // Return 0 if we catch any exception.
  }
}

// Exiting paste mode, now interpreting.

someCalculation: (i: Int)Int

scala> someCalculation(8)
java.lang.RuntimeException: Something went wrong...
  at .someCalculation(<console>:2)
  ... 28 elided

好的，很明显，发生了异常。那里没有惊喜。

但是请记住，如果我们可以将表达式替换为它的结果以使程序具有完全相同的含义，则表达式是引用透明的。在这种情况下，我们关注的表达式是j。让我们重构函数并j用它的结果替换（必须将抛出的异常的类型声明为整数，因为那是j's 类型）：

def someCalculation(i: Int): Int = {
  try {
    i + ((throw new RuntimeException("Something went wrong...")): Int)
  }
  catch {
    case e: Exception => 0 // Return 0 if we catch any exception.
  }
}

现在让我们在REPL中重新评估它：

scala> :paste
// Entering paste mode (ctrl-D to finish)

def someCalculation(i: Int): Int = {
  try {
    i + ((throw new RuntimeException("Something went wrong...")): Int)
  }
  catch {
    case e: Exception => 0 // Return 0 if we catch any exception.
  }
}

// Exiting paste mode, now interpreting.

someCalculation: (i: Int)Int

scala> someCalculation(8)
res1: Int = 0

好吧，我想你可能已经看到了：那次我们得到了不同的结果。

如果我们计算j然后尝试在一个try块中使用它，那么程序会抛出一个异常。但是，如果我们只是j在块中用它的值替换，我们得到一个 0。所以抛出异常显然违反了引用透明性。

我们应该如何以功能性的方式进行？通过不抛出异常。在Scala中（在其他语言中有等价物），一种解决方案是将可能失败的结果包装在Try[T]类型中：如果成功，则结果将是Success[T]包装成功的结果；如果发生故障，则结果将是Failure[Throwable]包含相关异常的；这两个表达式都是Try[T].

import scala.util.{Failure, Try}

def someCalculation(i: Int): Try[Int] = {
  val j: Try[Int] = Failure(new RuntimeException("Something went wrong..."))

  // Honoring the initial function, if adding i and j results in an exception, the
  // result is 0, wrapped in a Success. But if we get an error calculating j, then we
  // pass the failure back.
  j.map {validJ =>
    try {
      i + validJ
    }
    catch {
      case e: Exception => 0 // Result of exception when adding i and a valid j.
    }
  }
}

注意：我们仍然使用异常，只是不抛出异常。

让我们在REPL中试试这个：

scala> :paste
// Entering paste mode (ctrl-D to finish)

import scala.util.{Failure, Try}

def someCalculation(i: Int): Try[Int] = {
  val j: Try[Int] = Failure(new RuntimeException("Something went wrong..."))

  // Honoring the initial function, if adding i and j results in an exception, the
  // result is 0, wrapped in a Success. But if we get an error calculating j, then we
  // pass the failure back.
  j.map {validJ =>
    try {
      i + validJ
    }
    catch {
      case e: Exception => 0 // Result of exception when adding i and a valid j.
    }
  }
}

// Exiting paste mode, now interpreting.

import scala.util.{Failure, Try}
someCalculation: (i: Int)scala.util.Try[Int]

scala> someCalculation(8)
res2: scala.util.Try[Int] = Failure(java.lang.RuntimeException: Something went wrong...)

这一次，如果我们j用它的值替换，我们会得到完全相同的结果，而且在所有情况下都是如此。

但是，对此还有另一种看法：如果在计算 的值时抛出异常的原因j是由于我们的一些错误编程（逻辑错误），那么抛出异常——这将导致程序终止——可能被认为是引起我们注意的一种极好的方法。但是，如果异常是由于我们无法直接控制的情况（例如整数加法溢出的结果），并且我们应该能够从这种情况中恢复，那么我们应该将这种可能性形式化为函数返回的一部分值，并使用但不抛出异常。

于 2019-08-15T22:07:33.073 回答
4

引发异常可以是纯的或非纯的，它仅取决于引发的异常类型。一个好的经验法则是，如果异常是由代码引发的，它是纯的，但如果它是由硬件引发的，那么它通常必须被归类为非纯的。

这可以通过查看硬件引发异常时发生的情况来看出：首先引发中断信号，然后中断处理程序开始执行。这里的问题是中断处理程序不是您的函数的参数，也不是在您的函数中指定的，而是一个全局变量。任何时候读取或写入全局变量（又名状态），您就不再拥有纯函数。

将其与代码中引发的异常进行比较：您从一组已知的、本地范围的参数或常量构造 Exception 值，然后“抛出”结果。没有使用全局变量。抛出异常的过程本质上是您的语言提供的语法糖，它不会引入任何非确定性或非纯行为。正如 Don 所说的“它在语义上应该等同于使用 Maybe 或 Option 类型”，这意味着它也应该具有所有相同的属性，包括纯度。

当我说引发硬件异常“通常”被归类为副作用时，并不总是如此。例如，如果运行您的代码的计算机在引发异常时没有调用中断，而是将一个特殊值压入堆栈，那么它就不能归类为非纯的。我相信 IEEE 浮点 NAN 错误是使用特殊值而不是中断引发的，因此在进行浮点数学运算时引发的任何异常都可以归类为无副作用，因为该值不是从任何全局状态读取的，而是编码到 FPU 中的常量。

查看所有要求一个片段代码是纯的，基于代码的异常和 throw 语句语法糖勾选所有框，它们不修改任何状态，它们与调用函数或调用之外的任何东西没有任何交互，并且它们在引用上是透明的，但只有在编译器使用您的代码时才会这样做。

像所有纯与非纯讨论一样，我排除了执行时间或内存操作的任何概念，并在假设可以纯粹实现的任何功能都是纯粹实现而不管其实际实现如何。我也没有 IEEE 浮点 NAN 异常声明的证据。

于 2016-05-12T06:34:39.447 回答