love in C++, live on MFC

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

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

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

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

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

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

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

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

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

@alki
可能有一點，不過我的理解是"One way of measuring the quelity of a design is to see how well it handles variation"
hehe，摘抄的，不過我蠻同意的，因為實際項目中的變化，原超過想象

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

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

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

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