Java 或 C# 中异常管理的最佳实践 [英] Best practices for exception management in Java or C#

查看:28
本文介绍了Java 或 C# 中异常管理的最佳实践的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I'm stuck deciding how to handle exceptions in my application.

如果我的异常问题来自 1) 通过远程服务访问数据或 2) 反序列化 JSON 对象.不幸的是,我不能保证这些任务中的任何一个都能成功(切断网络连接,我无法控制的格式错误的 JSON 对象).

Much if my issues with exceptions comes from 1) accessing data via a remote service or 2) deserializing a JSON object. Unfortunately I can't guarantee success for either of these tasks (cut network connection, malformed JSON object that is out of my control).

因此,如果我确实遇到异常,我只需在函数中捕获它并将 FALSE 返回给调用者.我的逻辑是调用者真正关心的是任务是否成功,而不是为什么不成功.

As a result, if I do encounter an exception I simply catch it within the function and return FALSE to the caller. My logic is that all the caller really cares about is if the task was successful, not why it is wasn't successful.

这是一个典型方法的一些示例代码(在 JAVA 中)

Here's some sample code (in JAVA) of a typical method)

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;
}

我认为这种方法很好,但我真的很想知道管理异常的最佳实践是什么(我真的应该在调用堆栈中一直冒泡异常吗?).

I think this approach is fine, but I'm really curious to know what the best practices are for managing exceptions (should I really bubble an exception all the way up a call stack?).

关键问题总结:

  1. 是否可以只捕获异常但不将其冒泡或正式通知系统(通过日志或通知用户)?
  2. 对于不会导致所有内容都需要 try/catch 块的异常,有哪些最佳做法?

跟进/编辑

感谢所有反馈,在线找到了一些关于异常管理的优秀资源:

Thanks for all the feedback, found some excellent sources on exception management online:

  • Best Practices for Exception Handling | O'Reilly Media
  • Exception Handling Best Practices in .NET
  • Best Practices: Exception Management (Article now points to archive.org copy)
  • Exception-Handling Antipatterns

似乎异常管理是根据上下文而变化的事物之一.但最重要的是,他们在系统内管理异常的方式应该保持一致.

It seems that exception management is one of those things that vary based on context. But most importantly, one should be consistent in how they manage exceptions within a system.

另外注意通过过多的尝试/捕获或不尊重异常来防止代码腐烂(异常是警告系统,还需要警告什么?).

Additionally watch out for code-rot via excessive try/catches or not giving a exception its respect (an exception is warning the system, what else needs to be warned?).

另外,这是来自 m3rLinEz 的一个不错的选择评论.

Also, this is a pretty choice comment from m3rLinEz.

我倾向于同意 Anders Hejlsberg 和您的观点,即只有最多来电者关心操作是否成功.

I tend to agree with Anders Hejlsberg and you that the most callers only care if operation is successful or not.

从这条评论中,它提出了一些在处理异常时需要考虑的问题:

From this comment it brings up some questions to think about when dealing with exceptions:

  • 抛出这个异常有什么意义?
  • 如何处理它?
  • 调用者真的关心异常还是只关心调用是否成功?
  • 强制调用者管理潜在异常是否正常?
  • 您是否尊重该语言的惯用语?
    • 你真的需要返回一个像布尔值这样的成功标志吗?返回 boolean(或 int)比 Java(在 Java 中你只需要处理异常)更像是一种 C 思维方式.
    • 遵循与语言相关的错误管理结构:)!

    推荐答案

    你想捕获异常并将它们转换为错误代码对我来说似乎很奇怪.当后者在 Java 和 C# 中都是默认设置时,为什么您认为调用者更喜欢错误代码而不是异常?

    It seems odd to me that you want to catch exceptions and turn them into error codes. Why do you think the caller would prefer error codes over exceptions when the latter is the default in both Java and C#?

    至于你的问题:

    1. 您应该只捕获您可以实际处理的异常.只是在大多数情况下,捕获异常并不是正确的做法.有一些例外(例如,日志记录和编组异常线程之间),但即使在这些情况下,您通常也应该重新抛出异常.
    2. 你的文件中绝对不应该有很多 try/catch 语句代码.同样,这个想法是只捕获您可以处理的异常.您可以包含一个最顶层的异常处理程序来打开任何未处理的对最终用户有些用处的例外情况,但否则你不应该试图捕捉每一个异常每个可能的地方.

    这篇关于Java 或 C# 中异常管理的最佳实践的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆