zhuweisky

评论

#1楼 2005-09-10 12:18 lovesanni

个人而言，我更喜欢第二种签名设计，我觉得这样对于调用方来说，可以更自由一点   回复  引用    

#2楼 2005-09-10 12:18 fffly[未注册用户]

有道理，降异常逻辑下放到另外级别中的确很危险。

但是这些问题应该在你设计函数的时候就必须预见到。

现在知道异常的重要性了   回复  引用    

#3楼 2005-09-10 12:19 灵感之源的Forgio智能工厂      

经历跟作者一样，   回复  引用  查看    

#4楼 2005-09-10 12:48 可冰      

作者说得不错,但这也就带来了安全隐患,可能被有不良意图的人利用.其实我觉得应当看情况而定.有时候需要整个体系建立在一个非常坚实的基础上,那就必须要在最底层的模块处理绝大多数的错误.

@fffly
我不清楚你的意图是支持那方的.   回复  引用  查看    

#5楼 2005-09-10 13:28 阿水      

抛出异常不好吗   回复  引用  查看    

#6楼 2005-09-10 13:43 NoMagic      

我一般在函数开头都先检查参数的合法性，如不合法，则抛出异常。   回复  引用  查看    

#7楼 2005-09-10 13:45 idior[未注册用户]

其实dbc的思想已经很老很老了, 为什么没有被采用呢? 说明它本身有缺陷.
http://www.alphatom.com/content/view/246/43/
NContract早就出来了, 连对此感兴趣的楼主都不知道, 更证明了它的失败.   回复  引用    

#8楼 2005-09-10 14:25 萧寒

为什么要把什么事情都放到函数内处理；我一般使用第一种,调用者应该先检查再调用，而不是什么都丢给函数；加入你的GetMaxElement函数由别人完成，你能保证别人能完善的处理好一切吗？   回复  引用    

#9楼 2005-09-10 14:42 lovebanyi[未注册用户]

我喜欢第一种啊.第二种winAPI里面好多都是第二种方法. 还指针一下一下搞得C#调用起来感觉晕晕的.   回复  引用    

#10楼 2005-09-10 15:47 文野      

还是觉得在函数里抛出一个异常比较好，这样函数签名清晰，错误信息可自定义而且不丢失！   回复  引用  查看    

#11楼 2005-09-10 21:25 linkcd      

除了扔exception, 也可以用assert来做.
  回复  引用  查看    

#12楼 2005-09-10 22:43 学海无涯，回头是岸      

我比较喜欢第一种函数签名.
但是我一般把验证放在函数内部,对于无法返回最大值的情况抛出异常给调用者.

Public Function GetMaxElement(ByVal eleList As ArrayList) As Integer
If eleList Is Nothing Then
Throw New ArgumentNullException("eleList")
End If

If eleList.Count = 0 Then
Throw New ArgumentOutOfRangeException("eleList", "eleList集合的数量不能为0")
End If

Dim maxValue As Integer
'......
Return maxValue
End Function

如果eleList集合的元素不是int型的,是字符串或者其它类型的呢,或者是int型与其它类型的混合呢,如果不使用异常的话,那么调用者还需要先做个循环把集合的元素都检查一遍才能调用的话,还不如把检查工作放在函数内部,检查到非int型就抛出一个异常给调用者.
Throw New Exception(String.Format("eleList集合的第{0}个元素不是int型", index))

这仅仅是我个人喜欢的用法,至于这样做到底好不好,很想听听大家的意见.   回复  引用  查看    

#13楼 2005-09-11 22:21 qoo.net[未注册用户]

用Assert多好!   回复  引用    

#14楼 2005-09-12 09:39 yinh      

看到前几段，脑子里就出现一个概念，不错，和楼主想的一样，就是DBC，契约式编程，记得似乎在前两年的时候，接触过这个东西，可惜好像除了Effiel，其它语言都没有在语言层实现DBC，直到现在也是这样。当时还认为DBC也是OO的一项重要分支。
想问问idior，它本身的缺陷是什么？
我记得DBC的作者写过一本书，被认为是有史以来最好一本OO的书。   回复  引用  查看    

#15楼 2005-09-12 09:47 yinh      

如果在基本架构上就不支持DBC这样的东西，我觉得还是按。NET自己的习惯处理比较好，习惯处理是什么呢？其实咱们都用过string的一些方法，初学者用这些方法最容易得到一堆的越界异常等，所以，这里我想还是得抛出个异常，比如一个ArgumentNullException   回复  引用  查看    

#16楼 2005-09-30 10:47 王跃军[未注册用户]

其实对于你这种情况用
最直观的函数签名设计如下：
int GetMaxElement(ArrayList eleList) ;

是正确的，
针对eleList != null，eleList.Count > 0在.NET中应以异常的机制来处理

这是.net 企业级示例的推荐   回复  引用    

#17楼 2005-10-08 15:25 QuitGame      

我总结了一个设计原则：
不要让错误传播，在错误出现的发源地（萌芽期）就解决它！错误越是传播到最后，关于处理它的上下文就丢失得越多，对于错误的蔓延就越是爱莫能助！

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

这个总结明显有问题吧
错误如果不能被正确的处理 就应该让它传播   回复  引用  查看    

#18楼 2005-12-24 17:12 blahblah[未注册用户]

if((eleList==null) || (eleList.Count==0))
{
throw new UserDefinedException("element is null, or what ever")
}

try
{
int max = GetMaxElement(eleList) ;
} catch (UserDefinedException ex) {
//Handle your Exception here
}
  回复  引用    

#19楼 2006-02-10 12:46 bananafish[未注册用户]

似乎違背單元測試的做法,一般考慮reuse,必需正反的使用方式都考慮,既然是元件那就必需經的起考驗,誰知道以後誰會用這個元件.或許沒注意,這產生的bug將造成後續維護很大問題.不建議使用者自己先做確認.倒是丟出異常除了performance有些疑慮外,應該是不錯的方式
  回复  引用    

#20楼 2006-04-03 10:32 菜鸟(BB)[未注册用户]

你们有没有发现,有时候我们经常丢NULL值或空或不可转换类型(显/隐式)的对象/值给WINDOWS或.NET里的一些API呢?
它是让你先转换好或保证绝对正确的值,然后再传给它?还是在运行时抛出错误呢?
或者二种都有等等?
(纯属个人看法--菜鸟)
  回复  引用