love in C++, live on MFC

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

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

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

關于是用返回值還是異常一直都是個令人煩惱的話題。
不過我認為自己開發的程序如果只是自己使用的話，用返回值是最好的（當然適當的加上日志記錄最好了）。因為你自己知道什么時候作錯誤處理。如果是開發庫給別人使用，用異常可能比較好，因為你不知道你的客戶該怎么去處理錯誤，所以應該把錯誤處理的主動權交給客戶。  回復  更多評論
  

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

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

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

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

純屬誤導
唉，這里面什么人都有  回復  更多評論
  

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

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

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

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

BOOL 是MFC的習慣。  回復  更多評論