關於程序的健壯性



請做過大型軟件或在正規公司工作的人談談。自己的思路比較亂,而且問的問題比較幼稚。

1)你覺得自己的程序夠健壯嗎?
2)使用錯誤處理多還是異常處理多?
我覺得要根據自己使用的庫函數,如果庫函數使用的是錯誤處理(如:socket api),就用錯誤處理;如果庫函數使用的是異常,就用異常處理。如果好幾個庫混在一起使用,該怎么辦?你會封裝一下庫函數,使所有庫函數都使用異常?
3)一個大型軟件,是否需要建立許多自定的異常類?
4)你是否會對每個可能出錯或有異常的地方都進行處理?
一些不太容易出錯的地方,似乎不做檢查,如核心對象(CreateEvent),似乎沒人檢查創建是否成功。
5)new int; 
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次?
只是申請一個整型的空間,如果這都不成功,我想程序要完蛋了,程序做錯誤處理(顯示出現什么錯誤)的能力都沒有了,檢查毫無意義;也許該重啟操作系統了。
6)你是否感覺:本來挺簡單的程序,加上錯誤或異常處理就顯得很亂。你怎么使程序看起來有條理,談談經驗吧。

不是針對上面的幾個問題。隨便談談吧。

39 个解决方案

#1


new int; 
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次? 

我就說說這個吧
new是不用檢查是不是成功的,不成功他會跑出異常的,這個在hutter的那本more exceptional c++ style里面說到過

而且內存分配失敗,幾乎不可能。

#2



1)你覺得自己的程序夠健壯嗎? 
不夠,天天都怕客服打電話過來

3)一個大型軟件,是否需要建立許多自定的異常類? 

這個是肯定的

4)你是否會對每個可能出錯或有異常的地方都進行處理?

  人無完人,為了工作。為了客服,有時不能去做這些細節。
  大不了程序死了,讓他們重起一下

5)new int; 
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次? 

基本沒檢查過,覺得這種基本類型的檢查只在內存比較緊的環境下,如單片機等小東西上。

6)你是否感覺:本來挺簡單的程序,加上錯誤或異常處理就顯得很亂。你怎么使程序看起來有條理,談談經驗吧。 

看你代碼的風格了,記得看過一篇文章,說編程中風格第一,算法第二,平台第三,語法第四。呵呵。一種優異的風格是不會讓你亂的

#3


"內存分配失敗,幾乎不可能"

。。。
本來想說點啥的。。算了。。

#4


沒工作,只能幫頂了

#5


UP 

#6


友情UP!
一般內存應該不會分配失敗吧!除非多個大的進程在跑...

#7


沒經驗 
只有幫頂的份

#8


1)你覺得自己的程序夠健壯嗎? 
不夠,每次UT都好多問題,等release之后還總被tester測出好多。。。

2)使用錯誤處理多還是異常處理多? 
基本不使用異常處理,全是錯誤處理,自己也不習慣,也怕效率降低。。

3)一個大型軟件,是否需要建立許多自定的異常類? 
沒用過,感覺應該不用太多吧。

4)你是否會對每個可能出錯或有異常的地方都進行處理? 
一些不太容易出錯的地方,似乎不做檢查,如核心對象(CreateEvent),似乎沒人檢查創建是否成功。 

這個基本上都檢查,只要我能想到的地方,要不回頭core dump了,找起來就麻煩了。。

5)new int; 
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次? 
只是申請一個整型的空間,如果這都不成功,我想程序要完蛋了,程序做錯誤處理(顯示出現什么錯誤)的能力都沒有了,檢查毫無意義;也許該重啟操作系統了。 

一般我都檢查,你說的情況基本不會出現,int干嘛要用堆呢?給個棧變量就行了啊。。
至於檢查失敗的處理就得看什么位置了,咱也得有點容錯能力嘛,關鍵位置我就直接panic,報告詳細位置。。非關鍵位置就光取消當前請求就完了,返回失敗,讓別人處理去吧^_^

6)你是否感覺:本來挺簡單的程序,加上錯誤或異常處理就顯得很亂。你怎么使程序看起來有條理,談談經驗吧。 
合理使用宏定義,程序看着就好點。。
內存要求嚴格的程序,考慮用內存池,減少莫名其妙的失敗。。

#9


內存申請失敗是否要處理這個問題,
1)如果是一般的小型應用,並且不會長時間運行的,的確不應該出現這種情況,除非內存泄漏
2)如果是要處理大量數據,並且N多數據要存在內存里,這種情況還是很容易出現的,如果不處理申請失敗的話,定位問題可能會很難
如果處理了,寫個log或者給用戶個提示,讓用戶進行一些操作釋放一些內存,會更合理一些

#10


“一般”情況下當然不會分配失敗
同樣問題是,BUG往往都不是“一般”情況~

1)你覺得自己的程序夠健壯嗎? 
不才,這個問題不敢妄自回答,只能悄悄的說:扛得住壓力測試。

2)使用錯誤處理多還是異常處理多? 
錯誤處理多,實際上我很少使用異常處理。(我們team的共識是:異常如果發生了,就沒有所謂的處理這一說了。因為級別低的異常不catch程序也能繼續跑,級別高的異常你catch了也沒用。不過異常我不擅長,說錯了就拍磚。)


2.1)我覺得要根據自己使用的庫函數,如果庫函數使用的是錯誤處理(如:socket api),就用錯誤處理;如果庫函數使用的是異常,就用異常處理。如果好幾個庫混在一起使用,該怎么辦?你會封裝一下庫函數,使所有庫函數都使用異常? 

說實話並沒有封過這樣的庫,不過即使封一下,我也會盡量全都用錯誤處理。(這有個向后兼容的問題。)


3)一個大型軟件,是否需要建立許多自定的異常類? 
參與的項目不知道算不算大型,也許對效率要求太高,我們都是LOG居多,很少用異常類。
另外,C++對於異常的支持相比較后起之秀如JAVA,C#等,並不是強項!咱們有必要揚長避短么?

4)你是否會對每個可能出錯或有異常的地方都進行處理? 
一些不太容易出錯的地方,似乎不做檢查,如核心對象(CreateEvent),似乎沒人檢查創建是否成功。 

這個當然要處理,實際上symbian的二階段構造可以很好的解決你說的這個隱患。
(說白了,二階段構造就相當於下面這樣的代碼)
CTest temp = new CTest; (默認構造函數里只去初始化成員變量)
if(NULL == temp)
{
//todo
}
temp->XXXX() (就是緊接着調用一個專門的“所謂二階段構造函數”來申請資源)
另外,LZ你一句“似乎沒人”,槍斃了很多人。。。


5)new int; 
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次? 
只是申請一個整型的空間,如果這都不成功,我想程序要完蛋了,程序做錯誤處理(顯示出現什么錯誤)的能力都沒有了,檢查毫無意義;也許該重啟操作系統了。 

這個問題,我覺得仁者見仁,智者見智。所謂的健壯性,並不是單純的說遇到錯誤就處理,而應該是遇到了錯誤怎么處理(很少用異常,有問題請拍磚。)
如果這個new出來的int是一個關鍵的標記量?少了它程序就crash掉了!你覺得是否需要檢查呢?
換句話說,如果出現了錯誤,是讓程序退出?還是讓程序繼續跑?這個完全是看具體情況的,所謂差之毫厘,謬以千里。你的一個不經意的忽略,帶來的就是N個MD的焦頭爛額。
回到你這個問題,如果一個int都new不成功,最多最多就是讓你的程序主動退出(畢竟windows也設計了內存不足的提示)。而不是crash!


6)你是否感覺:本來挺簡單的程序,加上錯誤或異常處理就顯得很亂。你怎么使程序看起來有條理,談談經驗吧。 
實際上加上錯誤處理應該更清晰才對,而異常的話,還是那句話,我很少用,所謂沒有調查沒有發言權,就不談了。
至於怎么使程序看起來有條理??這個。。。問題實在太難回答。。。就好象goto早就被一棒子打死了一樣,條理,風格,更多時候是看個人喜好。
例如我喜歡NULL判空,例如if(NULL == xxx)
我還喜歡直接判值存在,例如if(xxx)
你可能會說前者風格不錯,后者就會讓人以為是bool值?這是廢話!
但這就是一種習慣,拜托~大家都是程序員,所謂天下代碼一大抄,看你會抄不會抄!所以必要的時候保留一點自己的個性,謝謝。
另外,一個訣竅是 --- 你的代碼,至少不要讓你的同事看着不爽~~

#11


幫頂~

#12


2,3對於一些common的類,重要操作等還是要有一些異常處理,有一些異常處理類..

#13


沒上班呢 嘿嘿

#14


up

#15


up

#16


能夠采用異常處理解決的,盡量使用異常處理

#17


UP一下
水平不夠談這個問題.

#18


樓主仿佛在看這太陽,卻拿不住太陽的疑惑

在程序編寫的時候寫異常安全的代碼,這樣會避免很多不必要的異常處理,通常過多的異常處理確實很失程序的美觀。
大型的軟件項目肯定有異常處理,這樣會使程序的框架清晰可見,還有寫出異常安全的代碼,你就沒有必要做出很多的異常處理

new int怎么判斷可以這樣寫
bool IsMem()
{
try{
int *a=new int(10);
delete a;
return true;
}
catch(std::NoMen)
{
return false;
}
}

寫程序的美觀最重要的是風格,

#19


你可以去看下C++必知必會,中的異常方面的,估計能解決你一點疑惑
呵呵,同時祝樓主新的一年快樂

#20


看看學習一下~

#21


up 

#22


up

#23


幫頂
三樓好有意思

#24


1)你覺得自己的程序夠健壯嗎? 
答:健壯
2)使用錯誤處理多還是異常處理多?
我覺得要根據自己使用的庫函數,如果庫函數使用的是錯誤處理(如:socket api),就用錯誤處理;如果庫函數使用的是異常,就用異常處理。如果好幾個庫混在一起使用,該怎么辦?你會封裝一下庫函數,使所有庫函數都使用異常? 
答:在同一個系統中,不管是用錯誤處理還是異常,在臨界的接口界面要做到統一,即要么錯誤處理,要么異常處理。所謂界面統一,即,如果系統采用錯誤處理,對於調用的庫如果采用異常,那么,對庫進行封裝,在封裝的函數內捕獲異常,返回錯誤代碼,統一到錯誤處理界面;反之亦然。
3)一個大型軟件,是否需要建立許多自定的異常類? 
答:這個應該鑒於應用框架的建立,不僅是大型應用,只要是具有一定的設計的系統,都可以考慮用還是不用自定義的異常類。自定義的異常類,不外乎是對異常的進一步分類。
4)你是否會對每個可能出錯或有異常的地方都進行處理? 
一些不太容易出錯的地方,似乎不做檢查,如核心對象(CreateEvent),似乎沒人檢查創建是否成功。 
答:基本上是這樣。
5)new int; 
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次? 
只是申請一個整型的空間,如果這都不成功,我想程序要完蛋了,程序做錯誤處理(顯示出現什么錯誤)的能力都沒有了,檢查毫無意義;也許該重啟操作系統了。 
答:一般情況下,我不會new一個int;一般情況下,我都會判斷是否為NULL;對於stl中的new,如果失敗會拋出異常,和普通意義下的new不一樣,一般我不會捕捉這個異常,除非是一個很大的內存空間的申請。
6)你是否感覺:本來挺簡單的程序,加上錯誤或異常處理就顯得很亂。你怎么使程序看起來有條理,談談經驗吧。
答:合理的任務划分,再給函數選擇一個最為貼切的名字,能夠使你的函數調用,在邏輯上一目了然,能夠准確的知道你在做什么;看到你的函數內部的代碼,也能很清楚的知道你是如何在做。不管你是使用錯誤處理還是異常處理。其中,我還有一個習慣,就是在每一個步驟之前,寫一行醒目的注釋,標志此段代碼的具體要做什么,從顏色(注釋的顏色)上也能夠知道,該部分代碼大致分了幾個部分。

新年快樂。2009年的第一個屬於我的回復。呵呵……

#25


程序寫出來容易 要健壯與高效實在很難 學習

#26


1)你覺得自己的程序夠健壯嗎?
這個是挺泛的問題,不同標准來衡量:如果按照工業級別應用的標准確實還不夠健壯,但如果是小規模的應用目前算健壯

2)使用錯誤處理多還是異常處理多?
我覺得要根據自己使用的庫函數,如果庫函數使用的是錯誤處理(如:socket api),就用錯誤處理;如果庫函數使用的是異常,就用異常處理。如果好幾個庫混在一起使用,該怎么辦?你會封裝一下庫函數,使所有庫函數都使用異常?

目前使用的大多是 錯誤處理,結合錯誤日志分析。沒有很特別的理由,可以說是不喜歡在代碼里面放一堆try catch,不僅僅會影響代碼可讀性而且在一定程度上影響了效率

3)一個大型軟件,是否需要建立許多自定的異常類?

個人覺得不是很必要
4)你是否會對每個可能出錯或有異常的地方都進行處理?
一些不太容易出錯的地方,似乎不做檢查,如核心對象(CreateEvent),似乎沒人檢查創建是否成功。

核心對象的創建確實如果做創建是否成功的檢查,但不見得需要在所有地方做異常處理
5)new int;
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次?
只是申請一個整型的空間,如果這都不成功,我想程序要完蛋了,程序做錯誤處理(顯示出現什么錯誤)的能力都沒有了


這個確實沒必要檢查這種小內存空間的分配

#27


該回復於2009-09-19 23:56:13被版主刪除

#28


還在大學中,學習了

#29


學習~

#30


up
up
up

#31


學習中...

#32


異常處理用的還是不是很習慣,看來還要多用啊!

#33


還是要看系統的規模的用途,就我自己的做的東西來可那,一般會為了簡單而減少一些錯誤的處理。但是對外部程序的使用或者說是外部提供的參數,都會做一定的檢查,自己系統內部的,一旦有意外的情況出現,一般直接就panic

#34


能夠采用異常處理解決的,盡量使用異常處理

#35


你覺得自己的程序夠健壯嗎? 
我的經驗是程序交給用戶后,要過三個月我才沒有問題返饋電話,問題包括Bug和需求變更,如果程序不夠健壯就會感改起來就會很惱火,便想辦法使它更為健壯.每完成一個項目就會更上一層樓.

#36


up

#37


看些專門的書籍吧

#38


1)你覺得自己的程序夠健壯嗎? 
答:健壯 
2)使用錯誤處理多還是異常處理多? 
我覺得要根據自己使用的庫函數,如果庫函數使用的是錯誤處理(如:socket api),就用錯誤處理;如果庫函數使用的是異常,就用異常處理。如果好幾個庫混在一起使用,該怎么辦?你會封裝一下庫函數,使所有庫函數都使用異常? 
答:在同一個系統中,不管是用錯誤處理還是異常,在臨界的接口界面要做到統一,即要么錯誤處理,要么異常處理。所謂界面統一,即,如果系統采用錯誤處理,對於調用的庫如果采用異常,那么,對庫進行封裝,在封裝的函數內捕獲異常,返回錯誤代碼,統一到錯誤處理界面;反之亦然。 
3)一個大型軟件,是否需要建立許多自定的異常類? 
答:這個應該鑒於應用框架的建立,不僅是大型應用,只要是具有一定的設計的系統,都可以考慮用還是不用自定義的異常類。自定義的異常類,不外乎是對異常的進一步分類。 
4)你是否會對每個可能出錯或有異常的地方都進行處理? 
一些不太容易出錯的地方,似乎不做檢查,如核心對象(CreateEvent),似乎沒人檢查創建是否成功。 
答:基本上是這樣。 
5)new int; 
你是否會為它檢查申請空間成功嗎?如果檢查,你會怎么處理?再申請一次? 
只是申請一個整型的空間,如果這都不成功,我想程序要完蛋了,程序做錯誤處理(顯示出現什么錯誤)的能力都沒有了,檢查毫無意義;也許該重啟操作系統了。 
答:一般情況下,我不會new一個int;一般情況下,我都會判斷是否為NULL;對於stl中的new,如果失敗會拋出異常,和普通意義下的new不一樣,一般我不會捕捉這個異常,除非是一個很大的內存空間的申請。 
6)你是否感覺:本來挺簡單的程序,加上錯誤或異常處理就顯得很亂。你怎么使程序看起來有條理,談談經驗吧。 
答:合理的任務划分,再給函數選擇一個最為貼切的名字,能夠使你的函數調用,在邏輯上一目了然,能夠准確的知道你在做什么;看到你的函數內部的代碼,也能很清楚的知道你是如何在做。不管你是使用錯誤處理還是異常處理。其中,我還有一個習慣,就是在每一個步驟之前,寫一行醒目的注釋,標志此段代碼的具體要做什么,從顏色(注釋的顏色)上也能夠知道,該部分代碼大致分了幾個部分。 



厲害,我現在能寫出來就是老天照應了。健壯性以后再談。

希望能成為樓主一樣的人物。

#39


平時基本埋頭寫程序,沒怎么認真去研究過這些問題,看來我這樣是不行的阿

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com