最佳实践错误处理

发布于 2024-10-15 08:03:29 字数 463 浏览 1 评论 0原文

我想知道用 C++、Java、C# 等编程语言处理应用程序中的错误的最佳方法是什么。

我想创建一个地方来存储与错误和警告消息相关的数字。

例如:

10000-> “无法读取文件”。 ... 20000-> “缓冲区溢出”。 ... 80000-> “关键的事情”。

我认为用数字来映射错误是一个很好的做法。无论使用哪种语言显示错误,都可以更轻松地找到错误。你们对此有何看法?有更好的方法吗?

还有一点是,如何存储它们,如何创建它们?

大的通用枚举是一个好的解决方案吗?我们必须将它们存储在数据库中吗?在一个文件中?

它应该是:

  • 很容易找到代码中的错误(即从数字中)。
  • 轻松添加新错误(如果不在同一位置,则两次不使用相同的错误号可能会很棘手)。

你们对此有何看法?

预先感谢您的帮助和建议!

I was wondering what would be the best way to handle errors in an application in programming languages like C++, Java, C#.

I thought of creating a place where to store number related to error and warning messages .

For example :

10000 -> "Can't read file".
...
20000 -> "Buffer overflow".
...
80000 -> "Critical stuff".

I think it's a good practice to map errors with numbers. It's easier to find the error no matter which languages it's displayed with. What do you guys think about that ? Is there a even better way to do that ?

Another point is, how to store them, how to create them ?

Is a big general enum a good solution ? Do we have to store them in a database ? In a file ?

It should be :

  • Easy to find an error in the code (ie. from the number).
  • Easy to add a new error (not using the same error number twice can be tricky if there are not at the same place).

What do you guys think about all that ?

Thanks in advance for your help and advices!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

双马尾 2024-10-22 08:03:29

使用错误代码来识别异常并不是一个坏习惯。

它在生产环境中非常有用,可以使日志文件更短,并且还可以用于国际化错误消息。

另一方面,在开发时,收到错误代码而不是带有有意义描述的完整错误消息可能会很烦人。开发人员必须去检查错误代码的含义。

在我的一个项目(使用 Java)中,我开发了一种混合方法。我的根异常有一个使用 Enum 类的构造函数。 Enum 类包含错误代码+默认错误消息的列表。类似于:

public enum ErrorCodes {

    VALIDATION_ERROR(5001, "One of the objects cannot be validated"),
    RESOURCE_NOT_FOUND(4004, "The requested resource does not exist"),

根异常还有其他构造函数,以便开发人员可以覆盖默认消息:

public CoreException(ErrorCodes _errorCode, final String message, final Throwable cause) {
   super(message, cause);
   errorCode = _errorCode.getCode();
}


public CoreException(ErrorCodes _errorCode, final String message) {
   super(message);
   errorCode = _errorCode.getCode();
}

当捕获异常时,异常处理程序可以决定(基于某些配置设置)记录错误和消息或仅记录错误。
更复杂的错误处理程序还可以根据错误代码从资源包中查找特定语言的消息。

Using error codes to identify exceptions is not a bad practice.

It can be very useful in a production environment to keep the log files shorter and also it can be used to internationalize error messages.

On the other hand, when developing, it can be annoying to received an error code instead of a full blown error message with meaningful description. A developer has to go and check what the error code is about.

In one of my projects (using Java) I have developed an hybrid approach. My root exception has a constructor that uses an Enum class. The Enum class contains a list of error codes + default error messages. Something like:

public enum ErrorCodes {

    VALIDATION_ERROR(5001, "One of the objects cannot be validated"),
    RESOURCE_NOT_FOUND(4004, "The requested resource does not exist"),

The root exception has also other constructors, so that a developer can override the default message:

public CoreException(ErrorCodes _errorCode, final String message, final Throwable cause) {
   super(message, cause);
   errorCode = _errorCode.getCode();
}


public CoreException(ErrorCodes _errorCode, final String message) {
   super(message);
   errorCode = _errorCode.getCode();
}

When the exception is caught the Exception handler can decide (based on some configuration setting) to log the error and the message or the error only.
A more sophisticated error handler could also look up a message in a specific language from a resource bundle based on the error code.

心是晴朗的。 2024-10-22 08:03:29

不要这样做。

我们有比 C 和 FORTRAN 更好的工具。

抛出异常并给出名称。 C# 和 Java 将提供调用堆栈。

C++ 可以告诉你异常的类型(只是勉强)

Do not do it.

We've got better tools than C and FORTRAN.

Throw exceptions and give the names. C# and Java will give call stacks.

C++ can tell you the type of the exception (just barely)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文