php中的异常真的那么有用吗？

3天前，在阅读了大量关于使用OOP的优点的书籍之后，我开始使用类作为练习，在OOP中重写我的一个脚本

现在我不知道我是否应该使用异常。他们似乎使我的工作更努力、更长时间

我的应用程序检查数据是否通过Ajax请求发送，然后通过脚本使用该信息

检查此示例：

 /*
 * The older way
 */

if($ajaxEnabled) {
    $error = errorWrap('Ajax error');
} else {
    $error = errorWithBackLinkWrap('NoAjax error');
}

function doSomething() {
    if(empty($POST['name'])) {
            die($error);
    }
}

/* 
 * OOP way
 */

class someClass {
    private $_ajaxEnabled;

    public function doSomething() {
        try {
            if(!$this->_isDateValid()) {
                if($this->$_ajaxEnabled) {
                    throw new ajaxException('Ajax error');
                } else {
                    throw new noAjaxException('NOAjaxError');
                }
            }
        } catch(ajaxException $e) {
            echo $e->getErrorMessage();
        } catch(noAjaxException $e) {
            echo $e->getErrorMessage();
        }
    }
}

此代码仅用于演示问题，因此我知道其中有一些未定义的函数：）

因此，在进行oop之前，错误处理对我来说比较容易，因为我只需要回显相应的错误

现在使用异常，在每个函数中，我必须首先检查连接类型，然后为每个抛出的异常编写2个catch函数，这将导致更大的代码

---

我对php中的OOP非常陌生，所以也许有一种更干净、更好的方法可以做到这一点，是吗？

当代码可以使用if语句优雅地处理错误时，不应该使用异常（就像您在示例中所做的那样）

例外情况适用于情况良好、例外的情况。不幸的是，这不是很简单，所以由程序员自己决定什么是例外。我认为一个好的经验法则是：

避免使用异常来表示 可合理调整的条件 作为典型的 方法的功能

---

From:

异常的有用性不在打印错误代码中。它是在捕捉错误，这样你就可以尝试解决它们，而不是用烟花爆竹来破坏它们。

如果你只需要显示错误消息，为什么不使用

catch (Exception $e)
{ print ($e->getMessage()); }

我个人讨厌例外情况。我在应用程序中不使用它们。我更喜欢返回（并期望）已定义状态代码的函数，以及在该级别处理可恢复错误的函数

在真正紧急的特殊情况下（如无法访问数据库服务器、文件I/O错误等），我倾向于触发并处理致命错误。（对象关闭仍将发生，因此需要关闭的任何连接等都将继续处理，只要它们处于关闭状态。）

第三方图书馆的例外情况我努力尽快抓住，并以我自己的方式处理它们

乔尔·斯波尔斯基在他那臭名昭著的作品中比我更能说明原因

---

请注意，这是一种观点和一种学派。有很多优秀的软件，其错误处理完全基于异常，这是非常好的。关键是一致性——要么你决定使用它们，要么你不使用

如果我理解你是怎么做的，我认为你做错了。错误的例外情况。它们适用于特殊情况。错误可能意味着很多事情（例如，用户没有在注册表上输入足够长的用户名）。这本身不应该是一个例外。但是，您可以使用异常来显示注册本身失败（取决于情况）

而且你不需要在每一个关卡都设置try/catch块。事实上，这是个坏习惯。仅当您可以处理异常，或者在允许异常继续之前需要执行其他操作时，才捕获异常。例如，如果您连接到一组远程网站，而第一个网站失败。您可以捕获该异常，然后使用第二个网站重试。然后继续，直到你没有更多的剩余（在这一点上，你会抛出另一个异常，表明没有网站可以被抓取）。另一个例子是，如果您正在生成图像。您有一个方法，该方法在生成引发异常的图像时执行一些计算。您希望捕获该异常，以便可以从映像进程中“清理”（以节省内存等），然后在完成后重新抛出它：

catch（ImageSomethingException$e）{/*clean-here*/throw$e；}

异常的真正威力在于它可以让您随心所欲地处理各种情况（因为异常可能会冒泡到程序顶部）。但只有在您知道可以处理（或至少需要清理）的情况下才能捕获异常。您几乎不应该在生产代码中执行

print$e->getMessage（）

就个人而言，我有一个我总是安装的。基本上，如果没有捕获到异常，它将记录该异常，然后生成一个500错误页面。这让我专注于在代码中可以处理哪些异常，而不是试图捕获所有异常（这通常不是一个好主意）

祝你好运…
异常作为一种错误处理机制，在概念和实现上与函数返回代码非常不同。您不能/不应该简单地将一个映射到另一个。在继续下一步之前，你应该先阅读和消化（然后再阅读一些）

如果您希望使用异常而不是返回代码来报告/处理错误，那么代码的结构应该会发生显著的变化

（*CodeProject链接是特定于.NET的，但几乎没有代码ti摘要。它主要是一篇易于适用于任何语言的最佳实践文章。）
大多数开发过程的能力都是有限的，也就是说，即使可以预测代码可能运行的所有可能情况（即，所有可能的输入组合、支持系统（如数据库、DNS、现有数据等）的所有可能状态）则不可能处理所有场景。使用异常允许您：

将一系列操作捆绑到一个实体中，以确定整体的成功/失败

用一位代码处理多种不同的故障模式

因此，是的，我想说异常处理是一种有用的实践，但不是处理常见故障模式的替代品