您的框架级 API(例如您的层)应该使用异常来处理真正的错误,并返回值来报告非关键错误。
public class Login
{
public bool AccountExists(string name) {
bool exists;
// do checking
return exists;
}
public LoginResult Login(string name, string password) {
// Try login
// If successful
return LoginResult.Success;
// What if the user does not exist?
return LoginResult.AccountNotFound;
// What about an error?
return LoginResult.Error;
}
}
public enum LoginResult
{
None,
AccountNotFound,
Error,
Success
}
在上面的示例中,您可以通过返回值报告操作的状态。对于 LoginResult,这甚至可以是一个值类型(结构),其中包含有关结果的更多信息(例如,字符串消息或其他内容)。因为这些类型的操作对非关键性的,所以这里没有必要例外。异常是昂贵的,并且并不总是需要报告错误。
现在让我们谈谈另一种类型的错误。逻辑开发人员错误。这些应该通过抛出异常来处理。以这个例子为例(假设我们有某种类型的 Account 具有 Role 属性)。
public class Foo
{
public bool IsAdmin(Account account) {
if (account == null) {
throw new System.ArgumentNullException("You cannot pass a null account!");
}
return account.Role == "Admin";
}
}
作为开发者,我们知道账户不应该为空,所以我们应该检查它,如果是则抛出异常。如果曾经抛出此异常,则它是调用代码中的一个错误,应修复为不传递空值。
现在我已经给出了两个粗略的场景,这如何适用于您的问题?这些是 API。无论您的 UI 层是什么,无论是 WinForm、WPF Window、WebForm 还是其他一些 UI,UI 都只需要使用 API。API 负责报告可供 UI 使用的信息,而 UI 负责以最适合该 UI 的方式显示信息。
框架 API 层不应该负责通过 UI 向用户报告错误。他们应该只负责向可以获取结果的开发人员报告错误,并以某种方式将其连接到 UI 层。例如,您永远不会显示消息框或从框架 API 写入控制台。您将返回一些 UI 可用于显示其自己的消息的结果。
I highly recommend that you read Framework Design Guidelines. It covers a lot of this material and is an extremely great read.