【发布时间】:2012-03-14 20:34:35
【问题描述】:
我正在反对古老的返回码与异常的辩论,并且可以针对具体示例提出一些建议。
我有一个简单的方法 Authenticate,它使用你的典型用户名、密码并在成功时返回会话密钥,否则返回失败原因。比如:
Guid Authenticate(string username, string password)
虽然不会向用户显示失败原因,但我想将其向上传递,以便他们采取适当的措施。
我认为有三组可能的反应:
1. 成功
2. 预期/常见故障,例如密码/用户无效,帐户被锁定
3. 异常/意外故障/异常,例如数据库连接失败等
我很高兴通过返回有效的 guid 来指示 1,通过冒泡的异常指示 3,但是我应该为 2 做什么?
我正在接近例外情况,但我不确定像密码错误这样的常见问题,这种情况可能在 50% 的时间发生,应该这样做吗?替代方案正在返回某种复杂的返回状态对象(如果成功,则包括 guid)或 out 参数?
【问题讨论】:
-
如果失败是意料之中的,那么在我看来,异常似乎不是可行的方法,因为它们不是异常的,而且是您可以处理的。
标签: c#