love in C++, live on MFC

為什么不返回為 long (HRSEULT)呢?

返回0表示成功,非0表示出錯(cuò)的原因  回復(fù)  更多評論
  

那么麻煩，用異常好了  回復(fù)  更多評論
  

關(guān)于是用返回值還是異常一直都是個(gè)令人煩惱的話題。
不過我認(rèn)為自己開發(fā)的程序如果只是自己使用的話，用返回值是最好的（當(dāng)然適當(dāng)?shù)募由先罩居涗涀詈昧耍Ｒ驗(yàn)槟阕约褐朗裁磿r(shí)候作錯(cuò)誤處理。如果是開發(fā)庫給別人使用，用異常可能比較好，因?yàn)槟悴恢滥愕目蛻粼撛趺慈ヌ幚礤e(cuò)誤，所以應(yīng)該把錯(cuò)誤處理的主動(dòng)權(quán)交給客戶。  回復(fù)  更多評論
  

@<font color="#FF00FF" >Stone Jiang
也可以，道理是一樣的，就是一定要利用好返回值，而不返回void
  回復(fù)  更多評論
  

從目前來看，用異常，在OOP方面已經(jīng)很普遍了。
它對于棧展開，對象自我析構(gòu)，和資源管理方面可以做得很好。
另外，在C++中，應(yīng)使用bool代替BOOL。  回復(fù)  更多評論
  

另外，對于樓主的例子，還是不要有返回值的好。因?yàn)檫@容易引起誤用。函數(shù)的用戶常常會以為SetName返回的是未設(shè)置以前的值，而不是錯(cuò)誤與否。  回復(fù)  更多評論
  

返回值這個(gè)東西，個(gè)人覺得是寧缺勿濫，設(shè)置返回值就要暗示使用者該調(diào)用可能失敗，不可忽略，而如果將目前不會失敗的函數(shù)也加個(gè)返回值，結(jié)果就像病毒一樣從使用了你的函數(shù)的調(diào)用鏈上的所有函數(shù)的返回類型可能都得強(qiáng)制使用你的返回類型，必竟通常只有最外層（界面層）會調(diào)用個(gè)類似GetLastError之類的函數(shù)查看具體錯(cuò)誤描述，程序中到處是以下代碼：
RESULTTYPE result;
result= Call_Func1();
if(!result)
{
RELEASE_RESOURCE1;
return result;
}
...
result= Call_Func1();
if(!result)
{
RELEASE_RESOURCE2;
return result;
}
...
最終，如果我是那個(gè)可憐的用戶，我要么放棄你的函數(shù)，要么放棄返回值檢測。
如果你好心的告訴用戶某函數(shù)會一直返回TRUE，那更糟糕，因?yàn)槟銓⑵茐哪愕暮瘮?shù)的用戶在使用函數(shù)方面的心理模型，就像你的軟件是設(shè)置成按左鍵彈出操作菜單，那么絕大多數(shù)右派遲早會有心理障礙。
　　事實(shí)上，在程序中大多數(shù)函數(shù)調(diào)用失敗是無法修復(fù)的，最終的結(jié)果是在界面上告訴用戶操作失敗了，因此異常會是錯(cuò)誤處理方面的更好選擇，即使錯(cuò)誤可修復(fù)，用異常也僅僅比函數(shù)調(diào)用多個(gè)把花括號而已，省去的是大把大把的return　result；語句。  回復(fù)  更多評論
  

純屬誤導(dǎo)
唉，這里面什么人都有  回復(fù)  更多評論
  

@alki
可能有一點(diǎn)，不過我的理解是"One way of measuring the quelity of a design is to see how well it handles variation"
hehe，摘抄的，不過我蠻同意的，因?yàn)閷?shí)際項(xiàng)目中的變化，原超過想象

我也是cpp新手，大家共同學(xué)習(xí)。
  回復(fù)  更多評論
  

我也覺得習(xí)慣性返回void是不好的。
只是上面舉的這個(gè)例子不夠恰當(dāng)罷了。
在調(diào)試的時(shí)候尤其有用。MFC的VERIFY宏不是用來看的。
按照txf 的看法，用API編程的人都該改行了。

個(gè)人認(rèn)為異常是你無法控制的錯(cuò)誤，至少VC對于異常的處理效率還是很低的，需要用到內(nèi)核調(diào)用。而且C++沒有象java那樣在語法上強(qiáng)制處理異常。

BOOL 是MFC的習(xí)慣。  回復(fù)  更多評論