例外管理问题 [英] Exception Management Question

问题描述

大家好，


我对如何处理异常有疑问。我正在使用一个

ASP.NET应用程序，它有一个表示层，业务层和

DataAccess Layer。我很困惑在哪里处理异常。说

例如我有一个要求，其中某些值必须介于

30-72之间，并且我在BL中进行此验证。如果值为
不在30-72之间，那么我会将异常抛回UI层。

这是正确的方法，还是我应该检查一下值和

使用一些变量或其他东西来告知UI层有关无效的

值。


因为这是业务需求我想要抛出一笔生意

例外。基本上Iam很难区分业务

异常和正常验证。什么样的例外应该是什么样的例外？b $ b b在商业层中尝试和捕获并抛出？有人可以请

帮我解决这个困惑吗？


谢谢

杰克

Hello All,

I have a question about how to handle exceptions. Iam working on an
ASP.NET application which has a presentation layer, Business Layer and
DataAccess Layer. Iam confused about where to handle exceptions. Say
forexample I have a requirement where certain value has to be between
30-72 only and Iam doing this validation in the the BL. if the value is
not between 30-72 then Iam throwing an exception back to the UI layer.
Is this the right way to do or should I just check for the value and
use some variable or something to inform UI layer about the invalid
value.

Since it is a business requirement i thought of throwing an business
exception. Basically Iam confused to differentiate between a business
exception and a normal validation. what kind of exceptions should be
tried and caught and thrown in the Business Layer? Can someone please
help me solve this confusion?

Thanks
Jack

推荐答案

，封装SqlException与DALException（您自己的类型）和

抛出它。在BOL中调用验证方法在Save（）方法中，如果失败

抛出一个BOLException，带有适当的消息，如果有额外的

信息，继承BOLException和添加属性以获取有关

错误的其他信息。 line


ValueOutOfRangeException：BOLException

{

private int minValue;

private int maxValue; < br $> b $ b ...

...

}


，别忘了，你必须验证用户输入你的gui代码也是如此。甚至

你必须使用javascript验证数据。你不能逃脱你的gui代码

来自业务规则。所以，我建议只有当3方派对客户和/或其他类型的GUI应用程序（如winform，

移动应用程序等）正在使用时，才会向您的BOL

添加验证功能相同的BOL dll / service应用....


有一个更好的选择（在我的观点中）检查db

中的这些约束（添加约束到你的桌子）。在BOL / GUI中完成其余工作。


您可能需要检查异常处理应用程序阻止..

in DAL, encapsulate SqlException vs. to a DALException (your own type) and
throw it. in BOL do call validation method in the Save() method, if it fails
throw an BOLException, with appropiate message and if there is additional
info, inherit from BOLException and add properties for additional info about
error. line

ValueOutOfRangeException : BOLException
{
private int minValue;
private int maxValue;
...
...
}

and dont forget, you have to validate user input in your gui code too. even
you have to validate data with javascript. you cant escape in your gui code
from business rules. so, i recommend add validation functionalty to your BOL
only if 3rth party clients and/or other kinds of GUI apps (like winform,
mobile apps etc.) are using the same BOL dll/service app....

there is a better option (in my oppinion) checking such constraints in db
(adding constraints to your table). and do the rest in BOL/GUI.

and you may want to inspect "Exception Handling Application Block"..

如果我没有错，你说我应该验证我的业务

UI层中的规则并检查这些验证是否在

BL中保持良好并向UI发送异常如果我发现

规则有任何异常，则为图层。或者我是否需要在UI和业务层进行验证？

如果Iam在UI和BL中进行验证，那么我会复制代码

不是吗？


另外从BL中抛出异常是任何商业规则都不是

满意是不是一个好习惯？

或者有没有其他可接受的模式??

If Iam not wrong you are saying that I should validate my Business
Rules in the UI layer and Check if those validations hold good in the
BL and throw exceptions to UI layer if I find any exception to the
rule. Or Do i need to do the validation in both UI and Business Layer?
If Iam doing validation in both UI and BL then Iam duplicating the code
isnt it?

Alsoo throwing the exceptions from BL is any business rule is not
satisfied is a good practice or not?
or is there any other accepted pattern for it??

首先，一般情况下应该保留异常情况以用于特殊的

情况。在您的情况下，您应该在

业务类中使用返回值（和其他返回信息）的评估方法

表示无效输入和问题的性质。这是一个

背后的设计：


你的UI层旨在捕捉客户端上可能出现的任何错误

方。在网上，这并不多，但它可以做任何简单的检查

在您正在使用的控件中可用。


您的公司图层提供验证方法，您的UI图层可以调用以完全验证数据。这些方法确实_not_ throw

例外：它们是你的

应用程序日常运作的一部分。验证错误_not_非常特殊。


您的业务层提供了更新数据层的方法。您可以

然后选择在您的数据层中进行验证。这个

验证_does_抛出无效数据的异常，因为数据层中的无效

数据意味着您的业务层是_broken_，并且

_is_"特殊。"


您是否在数据层中放置数据验证确实取决于

您想要将两个层耦合得多么松散或紧密。您的数据层中的数据

验证基本上表示您不相信您的

业务层来验证所有内容。从本质上讲，您可以根据业务层中的错误对数据层进行防火墙处理。也许是因为

你的数据层是一个Web服务，并且不知道（或信任）谁是b $ b来调用它。或者，也许是因为它是由一个不同的b
程序员编写的，而你正在努力防止误传。或者，

也许你只想要温暖，模糊的感觉来自

双重验证您的数据，从而确保它是坚如磐石的。在

任何情况下，如果你在数据层验证，你的数据层应该将b / b $ b抛出异常回到业务层，有效地说：你

传递给我糟糕的数据。你搞砸了你好了。


另一方面，你的业务层不应该将异常

返回给UI，除非用户界面传递它完全是错误的东西（例如，null

引用），这意味着UI层中有一个编程

错误。对于用户可能引入的任何无效垃圾，BL应该提供一种验证方法，通过参数/返回值返回有关

出错的信息。 （例如，我有返回错误消息的方法

。空返回意味着有效数据。）

First of all, exceptions should generally be reserved for exceptional
situations. In your case, you should have evaluation methods in your
business class that use return values (and other return information) to
indicate invalid input and the nature of the problem. Here is a
back-of-the-envelope design:

Your UI layer is designed to catch whatever errors it can on the client
side. On the Web, that''s not much, but it does whatever simple checks
are available in the controls you''re using.

Your business layer offers validation methods that your UI layer can
call to completely validate the data. These methods do _not_ throw
exceptions: they are part of the everyday functioning of your
application. Validation errors are _not_ "exceptional."

Your business layer offers methods to update your data layer. You may
then choose to do validation in your data layer as well. This
validation _does_ throw exceptions for invalid data, because invalid
data in your data layer means that your business layer is _broken_, and
that _is_ "exceptional."

Whether you put data validation in your data layer really depends upon
how loosely or tightly you want to couple the two layers. Data
validation in your data layer basically says that you don''t trust your
business layer to validate everything. You are, in essence, firewalling
your data layer against errors in your business layer. Perhaps because
your data layer is a Web Service and doesn''t know (or trust) who is
calling it. Or, perhaps because it was written by a different
programmer, and you''re trying to guard against miscommunication. Or,
maybe you just want the warm, fuzzy feeling that comes from
double-validating your data and thus ensuring that it''s rock-solid. In
any case, if you validate in your data layer, your data layer should
throw exceptions back to the business layer, effectively saying: "You
passed me bad data. You screwed up. You''re broken."

Your business layer, on the other hand, should never throw an exception
back to the UI, unless the UI passes it totally the wrong thing (a null
reference, for example), meaning that the UI layer has a programming
error in it. For any invalid junk that the user can possibly introduce,
the BL should offer a validation method that returns info about what
went wrong via arguments / return value. (For example, I have methods
that return error messages. A null return means valid data.)

这篇关于例外管理问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！