错误表示和处理
我正在设计一个跨平台应用程序保护库来与加密狗进行通信。加密狗能够发送和接收数据块，创建和删除加密狗内部文件系统内的目录和文件等。简单来说，主要的加密狗对象具有实现所有这些功能的方法。不幸的是，这些方法中的任何一个都可能失败。现在我正在考虑如果他们这样做了该怎么办:)
最明显的解决方案是从所有这些方法返回一个布尔类型结果来指示它们是失败还是成功。然而，这会导致丢失有关错误性质的详细信息。
下一个可能的解决方案是返回错误代码，但错误类型将超过 30 种。另外，我需要设计一个单独的函数来将所有这些返回代码转换为更易读的字符串表示形式。
第三种解决方案是返回布尔类型结果，但在主加密狗对象中保留错误状态对象，以便可以使用 GetLastError() 检索它，例如方法。我正在考虑使用这个。
现在是我的问题。是否还有其他合理的错误表示和处理模式，您建议我在我的案例中使用什么？
谢谢， 伊利亚
I am designing a cross-platform application protection library to communicate with a dongle. The dongle is able to send and receive blocks of data, to create and delete directories and files inside the dongle's internal file system, etc. To put it simple, the main dongle object has methods to implement all of these functionalities. Unfortunately, any of these methods may fail. Right now I am thinking about what to do if they do :)
The most obvious solution is to return a boolean type result from all of these methods to indicate if they fail or success. However, this leads to a loss of details about the nature of an error.
The next possible solution is to return an error code, but there will be more then 30 types of errors. Also, I will need to design a separate function to convert all of these return codes to a more readable string representation.
The third solution is to return a boolean type result, but to keep an error state object in the main dongle object so it will be possible to retrieve it using GetLastError() like method. I am considering about using this one.
Now is my question. Are there any other reasonable error representation and handling patterns and what do you suggest me to use in my case?
Thanks,
Ilya
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在您提供的选项中，最好的方法是使用返回代码。通常，返回代码为零表示成功，并且每个其他返回代码都有其自己的正整数值。 30 个错误条件并不多。正如您所说，您必须编写代码将这些代码转换为人类可读的内容，但无论如何您都必须这样做。
不过，我会考虑编写一个异常层次结构来代替错误代码来执行此操作。异常可以比返回代码更具表现力，并且如果处理得当，代码可以更干净。您通常会设计您的库，以便每种类型的错误返回条件都有一个不同的异常类，每个异常类最终都派生自
std::exception。what()方法为您提供了放置人工消息构建的位置，并且异常本身的类型描述了错误。有些人会告诉您，例外“仅”适用于特殊情况，例如您的计算机着火或其他情况。这是一个备受争议的主张。我告诉你那是无稽之谈。仅仅因为它被命名为“例外”并不意味着您的计算机必须着火才能使用它。异常给你带来很多好处，其中最大的好处之一就是堆栈展开。仅仅因为某些错误“足够糟糕”的任意行而阻止自己使用它们是愚蠢的。
Of the options you have presented, the best is to use return codes. Typically a return code of zero indicated success, and each other return code has its own positive integral value. 30 error conditions isn't many. As you've said, you'll have to write code to translate these codes to something human-readable, but you have to do this anyway.
I would consider writing an exception hierarchy to do this instead of error codes, however. Exceptions can be more expressive than return codes, and the code can be cleaner if done properly. You would typically design your library so that there is a different exception class for each type of error return condition, each derived ultimately from
std::exception. Thewhat()method gives you a place to put the human-message building, and the type of the exception itself describes the error.There are those who will tell you that exceptions are "only" for exceptional circumstances, like your computer caught fire, or something. This is a hotly debated assertion. I'll tell you that is nonsense. Just because it is named "exception" doesn't mean your computer has to catch fire in order to use it. Exceptions give you a lot of benefits, one of the biggest being stack unwinding. Preventing yourself from using them simply because of some arbitrary line where errors are "bad enough" is silly.
您也可以尝试使用 std::exception。它允许您说出错误是什么及其背后的本质。
You could also try using std::exception. It allows you to say what the error is and the nature behind it.