0

在 OO 编程中,是否有一些关于处理多个错误的概念模式、想法?

例如,我有一个执行一些检查的方法,并且应该为发现的每个错误返回一条错误消息

['名称太短', '名称包含无效的 unicode 序列', '名称太长']

现在,我应该使用一组异常(不是抛出的异常)吗?

或者像这样更好:

class MyExceptionList extends Exception{
  public Void addException(Exception e){}
  public Array getExceptions(){}
}

这个论点背后的任何理论将不胜感激!

(这不是对特定编程语言的要求,而是纯粹的理论要求)

先感谢您

4

4 回答 4

1

根据我多年的经验,最好通过在所有级别记录错误来处理错误,并从函数中返回真/假,指示成功/失败。

日志记录依赖于实现。它可以是文件、内存,您可以记录消息、唯一编号等,只要日志能够让您查明错误的确切位置。

我有时会使用异常,在我执行许多操作的情况下,每个操作都取决于其前身的成功。这使代码更干净,没有if用于错误检查的 s。然而,这不是主要关心的事情。主要是记录错误,并返回成功/失败。需要成功/失败,以便您可以决定是否继续正常方式(例如不执行缩进操作,因为读取大小可能会超出内存)。

还有两个重要的注意事项:

1) 你必须构建一个超级简单的 API 来报告(记录)你的消息,否则你会发现自己推迟了这个关键的事情,最终没有去做。

2) 日志或报告必须易于查看,并在出现问题时告知您问题。否则,您可能会发现自己根本没有使用错误报告机制。

这对我来说是一个非常重要的主题,我相信它是软件工程中最重要的问题之一。你可以在我的网站上阅读更多关于它的信息

于 2012-12-15T17:35:04.407 回答
1

不幸的是,许多语言和框架(包括 C++、Java 和 .net)使用异常处理机制,该机制需要异常对象的类型来同时回答许多问题,包括:

  1. 发生了什么
  2. 除了堆栈展开之外还需要采取什么行动
  3. 在什么时候系统应该被认为处于“已知”状态,至少对于异常所指示的问题。

不幸的是,虽然这些问题的答案有些相关,但它们实际上远非 100% 相关。不幸的是,假设异常的类型足以回答所有这些问题,因此很难明智地处理许多情况。

如果您可以控制所有可以抛出的异常,那么使用异常处理范例可能会有所帮助,其中异常处理对象包括一个虚拟IsResolved属性或方法以及一个ShouldCatchAs<T>属性或方法,该属性或方法T在异常需要时返回作为T. 这样的范例将能够顺利处理从早期异常展开堆栈时发生异常的情况(现有异常和新异常将被包装到复合异常对象中,其ShouldCatchAs属性将结合原始异常的属性,并且只有当两个原始异常的属性都相同时,IsResolved属性才应该返回)。trueIsResolved

I don't know any way to integrate such behavior into the existing frameworks unless one catches and wraps all exceptions that don't fit the paradigm, but perhaps future frameworks can facilitate such things.

于 2012-12-16T02:23:08.453 回答
0

那你不应该扔Exceptions 。

AnException用于特殊情况。在验证方法上发现的错误不被视为“异常”,很明显会发生验证错误。

例如,当您尝试连接到数据库失败时,就会出现异常情况。

您应该将所有验证错误记录到一个数组中,然后将其格式化并根据需要显示。

于 2012-12-15T17:06:17.757 回答
0

异常并非用于验证,它们旨在在执行期间发生与预期不同的事情时创建。这就是为什么你不能一次创建许多异常,但是异常可能是因为发生了其他一些异常而导致的,这就是为什么它们可以有一个名为 case 的父异常。

于 2012-12-15T17:07:08.787 回答