健壮先还是易测先

这句能再解释一下吗？什么意思？
我不怎么理解。

我在开始的时候，程序中还使用了很多的异常捕捉的代码，
比如在截取字符串的时候，结果也被指出不规范，理由是：如果这里有可能出现异常的情况下，应该提交申请，然后专门的人对此设计进行修改，否则就不应加入异常捕捉代码。

后来，直接将传递过来的参数作为正确的数据就可以，我认为这样不会有什么问题！并非异常捕捉做的越多越好！

一般來說 try catch確實是不應該多寫的  因為會隱藏很多問題 還在一點點程度的影響性能
不過寫這種方法的時候  比如說 截取字符 的方法  不管從哪方面來說 也不應該考慮傳來的數據肯定是正確的數據  我不用做check  因為寫這個方法的人不會知道這個方法有多少人調用 而調用的人知道不知道這個規則 他會不會在調用這個方法之前確認他傳過來的數據
所以做有可能扔出異常的操作的時候  必要的check肯定是要有的  不是說用try把他包起來 是在做之前做比如說 長度check 或者非空check
沒有check的src在我這肯定是不過關的  前幾天剛發回去幾個 讓他們確認傳過來的數據



這種想法是最要不得的 如果說你寫這個方法的時候衹是寫在自己的action或者server裏 而你們的框架是不會調用別人的action或server裏的方法的話  那沒問題
而如果你寫的是大家共通的 要有很多人用的方法的話 就不應該這麽考慮 這就很明顯是方法本身的問題
你見過JDK裏面方法的DOC裏寫了 參數肯定要非空 或者說 長度在10以內 麽

我想这句话是关键，我们处理的这些方法是非共同的，不但如此，这些处理应该是偏重于模型的（这里表达可能有误），一环扣一环的。
另外，因为数据库使用了DB2，因此只要数据库中有数据，长度不足的问题是不会出现的，除非数据库字段的长度设置有误。

我想是这样吧

个人感觉健壮性跟易测试性是不矛盾的，怎么就弄矛盾了呢？


象这样的代码是健壮的吗？是易测试的吗？我看都不是
既然你的程序是要给其它程序调用的，怎么可以不考虑出错的可能呢？最起码遇到不符合预期条件的调用（比如参数的格式不对），要给出有意义的异常信息，方便查找错误。你不考虑这些，到时有问题还是得找你去分析、解决（因为别人可能根本不知道为什么出错），这实际上就是给自己留了陷阱，早晚自己会踩进去......
健壮的代码才是易测试的，而改进易测试性通常也能提高健壮性。两者不应该偏废

我还是以为有点问题，如果每个模块都进行了认真的测试的话，怎么可能会出现上面的问题呢？
难道调用的模块就不进行测试了？