写一个除了抛出异常之外什么都不做的方法是不好的做法?

时间:2012-01-05 00:22:16

标签: c# asp.net-mvc asp.net-mvc-3 exception

标题几乎说了但是这里有一些背景知识:

我有一个ASP.Net MVC应用程序,我需要检查存在的文件路径列表。如果任何路径不存在,则返回错误。

目前,我有一个实现OnException事件的基本控制器。在这里,处理任何未处理的异常,并将错误页面返回给用户,并显示异常消息。

对我来说,执行上述检查的最简单方法是编写一个检查每个路径是否存在的方法,如果其中任何一个路径失败,我只需抛出(并记录)异常。然后,基本控制器处理此异常,并将相应的消息返回给用户。

我的问题是,这样做感觉就像是不好的做法。我正在编写一个返回void的方法,它的唯一目的是在极少数情况下抛出异常,其中一条路径不存在,在大多数情况下它什么都不做。这是个坏主意吗?

3 个答案:

答案 0 :(得分:8)

这没有错。

.NET框架也是这样做的:例如,CancellationToken有一个方法ThrowIfCancellationRequested,根据某些条件,它只会抛出或不投掷。

另一个示例:Dispatcher' VerifyAccess方法,它检查调用者是否与应该访问控件的线程在同一个线程上,如果没有则抛出。

答案 1 :(得分:0)

On .net存在执行抛出新notimplementedexception的选项,因此您可以创建方法并在以后实现它们。所以这不是一个坏习惯,不好的做法是在将应用程序发布到生产时将它们留在那里。无缘无故犯错是不好的做法。

对于TDD(测试驱动开发)也非常有用,您创建方法,然后使用未实现的异常失败的单元测试,最后实现方法以通过测试。

正好回答你问题的标题,但是你应该重新命名这个问题因为你的方法有所帮助。如果它做了某些事情并且总是抛出异常是不好的做法,异常是昂贵的,你应该记录错误并继续前进,毫无例外。你最好做一个返回布尔值的PathExists函数,这是一个更好的解决方案。 (即使有人无缘无故地投票给我-1)Heheh)

答案 2 :(得分:0)

有些人可能会说这是一个坏主意,但有时候,没有明智的选择。如果您想引发异常以将错误传回给某个调用者(可能是由不透明的第三方代码与提升者隔离),那么就这样做。最后的仲裁者 - '它有用吗?'