无效的用户输入是否是引发异常的有效原因?

一般来说,无效或不合格的输入不被认为是“例外”,应该使用除异常之外的其他事项来处理。但请注意,这是一条指导原则——在某些情况下,使用异常处理问题可能会产生更好的代码。

预期的情况是用户输入无效。您希望它像有效输入一样经常发生。如果是这样,抛出异常可能太多了。

在数据库端,如果尝试创建具有重复名称的新用户记录,则抛出。这是一种特殊情况,在数据库方面你无能为力。你 还提供

在UI端,您允许用户选择一个名称,然后检查其可用性。UI端负责与用户交互并告诉他们选择另一个名称。由于能够检查名称的有效性,UI永远不会传入重复的名称。。。 除非发生特殊情况

在这种情况下,我同意这本书。您的数据库是应用程序的最低级别,不应该在其中编写太多的业务逻辑(如果发生了A,则执行B,除非是C,然后是D)。这并不意味着您不能在数据层中提供有用的方法来避免异常。

异常是异常的东西——这就是为什么它们被称为异常。一般来说,错误的用户输入不是例外,应该通过向用户发送某种类型的通知来优雅地处理。另外,不要忘记异常确实会破坏代码的性能。

http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx http://msdn.microsoft.com/en-us/magazine/dd419661.aspx

一般来说没有,但我能想到一个例外的规则,我个人遇到的。

我们要求域对象始终有效。如果试图创建或传递错误数据,我们会从域对象引发异常。不过,在这种情况下,这是一种“例外情况”。为什么?逻辑是,坏数据永远不应该进入域。在调用堆栈的某个地方,可以将无效数据输入到系统中—无论是通过错误计算、来自底层数据源的坏数据还是用户输入。

因此,如果您希望查看数据是否未经验证,或者验证规则本身是否与您的数据持久性方法/功能不一致,那么我认为抛出是完全正确的。在所有其他情况下,我倾向于避免抛出无效输入。

如果您根据特定标准显式验证用户输入,并计划根据验证结果采取行动,那么如果您不抛出异常,您会发现这要容易得多。

我听说并读到,良好的OO实践不会对用户输入抛出异常。然而,这种逻辑确实让我有点挠头。想想这里的历史。回到C编程中,我可能会编写如下函数:

int validateUserInfo(struct info)
{
    //...
}

调用方将执行以下操作:

int errorCode = validateUserInfo(info);
if (errorCode != 0)
    handleError(errorcode);

据我所知,编写异常处理是为了避免将错误条件作为上述方法的返回值返回。然而,如果我不使用异常处理来验证用户信息,我是否会返回一些关于坏数据的条件,导致我使用if语句检查无效数据以更改“成功”的执行流?

现在,我似乎必须检查返回值并将其包装在try/catch中。C++/C#/Java类中的validateUserInfo方法可能会为“异常错误”引发异常,并将“坏数据”验证错误作为返回值或其他机制返回。这不是为了一些“OO规则”而使代码更复杂吗?

当然,OO纯粹主义者会带着一些替代方案回来,这样我就不必在试图消除此场景时实际返回“坏数据”验证错误,但事实是,在某个地方,有人会编写代码来检查验证错误,并为异常编写try/catch块。

如果异常处理很慢,那么编译器开发人员应该修复它以加快处理速度。这不应该成为避免例外的理由。

• 你的项目是否有标准(那些标准胜过所有其他标准)
• 还有其他选择吗?
• 你能在方法内部适当地处理它吗?

当然,总有一些减轻处罚的情况。

我同意其他回答者的观点,即错误的输入是意料之中的,不应该例外处理。但是,如果您发现恶意输入(sql注入尝试或类似的情况),则可能会出现异常。