已关闭 。这个问题是基于观点的。它当前不接受答案。

想改善这个问题吗？ 更新问题，以便通过编辑此帖子以事实和引用的形式回答。

4年前关闭。

我一直在决定如何处理应用程序中的异常。

如果我的异常问题很大程度上来自于1）通过远程服务访问数据或2）反序列化JSON对象。不幸的是，我不能保证其中任何一项都能成功（切断网络连接，无法控制的格式错误的JSON对象）。

结果，如果确实遇到异常，我将在函数中捕获该异常并将FALSE返回给调用方。我的逻辑是，调用者真正关心的只是任务是否成功，而不是为什么任务没有成功。

这是典型方法的一些示例代码（在JAVA中）

public boolean doSomething(Object p_somthingToDoOn)
{
    boolean result = false;

    try{
        // if dirty object then clean
        doactualStuffOnObject(p_jsonObject);

        //assume success (no exception thrown)
        result = true;
    }
    catch(Exception Ex)
    {
        //don't care about exceptions
        Ex.printStackTrace();
    }
    return result;
}

我认为这种方法很好，但是我真的很想知道管理异常的最佳实践是什么（我真的应该一直在调用堆栈中冒泡一个异常吗？）。

关键问题总结：

1. 是否可以只捕获异常但不将其冒泡或正式通知系统（通过日志或向用户的通知）可以吗？
2. 对于没有导致一切都不需要try / catch块的异常，有哪些最佳实践？

跟进/编辑

感谢所有反馈，在线找到了一些有关异常管理的出色资源：

• 异常处理的最佳实践 奥赖利媒体
• .NET中的异常处理最佳实践
• 最佳实践：异常管理（本文现在指向archive.org副本）
• 异常处理反模式

异常管理似乎是随上下文而变化的事物之一。但最重要的是，它们在系统内如何管理异常应该保持一致。

另外，要通过过多的try / catching来注意代码是否腐烂，或者不要对异常给予尊重（异常警告系统，还有什么需要警告的？）。

另外，这是m3rLinEz的不错选择。

我倾向于同意安德斯·海斯伯格（Anders Hejlsberg）和您的看法，即大多数致电者只关心手术是否成功。

通过此注释，它提出了一些在处理异常时要考虑的问题：

• 抛出该异常有什么意义？
• 处理它有什么意义？
• 呼叫者是否真的在乎异常，还是在乎通话是否成功？
• 强制调用方正常管理潜在异常吗？
• 您是否尊重语言的本质？
  • 您是否真的需要返回类似boolean的成功标志？返回布尔值（或整数）比C语言更像C语言（在Java中，您将处理异常）。
  • 遵循与语言相关的错误管理结构：)！