發(fā)布時間：所屬分類：計算機職稱論文瀏覽：1次
摘 要： 在當前有關(guān)計算機程序開發(fā)建設管理的新應用措施有哪些，如何來判斷程序的各個環(huán)節(jié)呢，又該怎樣來解決異常的事項呢?本文做了詳細的介紹。文章選自：《計算機應用與軟件》,《計算機應用與軟件》主要面向從事計算機應用和軟件技術(shù)開發(fā)的科研人員、工程技術(shù)人員
在當前有關(guān)計算機程序開發(fā)建設管理的新應用措施有哪些，如何來判斷程序的各個環(huán)節(jié)呢，又該怎樣來解決異常的事項呢?本文做了詳細的介紹。文章選自：《計算機應用與軟件》,《計算機應用與軟件》主要面向從事計算機應用和軟件技術(shù)開發(fā)的科研人員、工程技術(shù)人員、各大專院校師生、計算機愛好者。致力于創(chuàng)辦以創(chuàng)新、準確、實用為特色，突出綜述性、科學性、實用性，及時報道國內(nèi)外計算機技術(shù)在科研、教學、應用方面的研究成果和發(fā)展動態(tài)的綜合性技術(shù)期刊，為國內(nèi)計算機同行提供學術(shù)交流的平臺。注重刊登反映計算機應用和軟件技術(shù)開發(fā)應用方面的新理論、新方法、新技術(shù)以及創(chuàng)新應用的文章。
摘要：編寫一個程序去生成另外一個程序的過程被稱之為原編程(Metaprogramming)。它可以被應用于讓程序根據(jù)給定數(shù)據(jù)生成代碼。單一一個程序可能不足以表示給定數(shù)據(jù)的所有方面。讓一個程序去分析這個數(shù)據(jù)并生成新的程序去處理數(shù)據(jù)所有的方面可能會容易一些。Lisp就是一例支持這種編程模式的程序語言。
關(guān)鍵詞：程序開發(fā),計算機應用,論文發(fā)表
從接觸異常開始我就弄不明白她,不會用她,想在系統(tǒng)中是異常機制發(fā)揮的淋漓盡致,進行了很多嘗試,利用異常控制程序流程,利用異常做數(shù)字的判斷函數(shù),利用異常消除系統(tǒng)中可能出現(xiàn)的惱人的異常提示框,為了更好了利用異常看了很多關(guān)于異常的文章,直到有一天看到了一句話——“永遠不要去處理你不知道怎么處理的異常”,這才恍然大悟,感覺自己一直在用強大的異常機制干一些旁門左道的是事,更談不上理解異常在程序中的地位和意義,異常其實一種報告機制,“她以一種不可回避的方式報告程序中所出現(xiàn)的問題”,她幫助程序員走向正確的道路,她忠實的向程序員提供錯誤報告,她希望有誰能重視并處理掉她報告的問題,哈,真不敢想象,沒有了異常機制該如何編制高質(zhì)量的程序!下面就個人的理解和看法瞎說幾句,敬請各位批評指正,不勝感激!
異常的工作原理,在有問題的地方產(chǎn)生異常,馬上停止當前的工作,轉(zhuǎn)向異常處理代碼,如果找不到異常處理代碼,就會見異常向一層匯報,上一層接到異常會做同樣的事,轉(zhuǎn)向異常處理代碼,或者再將異常向上匯報,這樣逐層間錯誤傳遞出去,直到有一層處理了異常或是一直報告給程序的使用者——用戶。這個層就是調(diào)用棧,當用戶A運行程序B,B從函數(shù)C開始執(zhí)行,調(diào)用函數(shù)D,再調(diào)用函數(shù)E,再調(diào)用函數(shù)F,這時F出現(xiàn)了異常,那么這個異常的調(diào)用棧就是A(棧底)—〉B—〉C—〉D—〉E—〉F(棧頂),這個異常就會沿著這個棧從棧頂開始向棧底的方向報告,如果在函數(shù)C中有對這個異常的處理代碼,那么這個異常的報告鏈就是F—〉E—〉D—〉C。可以看出,如果在完整的調(diào)用棧中沒有處理這個異常的代碼,用戶A就成了異常報告的終點,向windows界面系統(tǒng),會彈出一個惱人的消息對話框哈。
那么用戶A向誰報告呢,哈哈,這個已經(jīng)不屬于程序的范圍了,感覺用會對程序而言好像上帝一樣,訴說痛苦已經(jīng)讓上帝都聽到了,就心滿意足了哈哈,看來程序真虔誠哈哈。對于異常這個特性,也可以比喻成下屬向上級報告問題,如果下屬知情不報,問題就嚴重了,你要是領(lǐng)導知道下屬是這樣的八成就踢了他,相反如果你有一個報告機制健全的下屬隊伍,哈哈你就威風了。日本企業(yè)文蛤中有個宗旨——聯(lián)絡,商談,報告,其實就是想讓員工都具有向上級匯報的習慣。現(xiàn)在再看看程序,哈哈,你不用給她們灌輸什么企業(yè)文化,不用她們講述什么報告的重要性,她們本身就是忠實報告的,如果把程序員比作企業(yè)老總,那么程序就是訓練一隊有素的員工。
怎樣處理異常。在這里有個原則就是“永遠不要去處理你不知道怎么處理的異常”,
也就是只處理你知道如何處理的異常,對那些你不知道的異常必須廣開言路,并積極地向上級匯報。什么叫知道如何處理呢?先說一下處理異常有哪些方式,大體有,彈出提示消息框(這個消息框不同于那個惱人的異常報告消息框,她是捕獲異常后,根據(jù)處理的具體環(huán)境程序員主動編寫的友好的提示消息框),記錄錯誤日志,吞掉,做善后工作等等,那么出現(xiàn)異常時就要站在出現(xiàn)異常的模塊的立場上考慮一下我應該選擇哪種處理方式呢?如果不能做出選擇就選擇不處理,即向上級報告。
舉個例子,函數(shù)Fun1是創(chuàng)建并返回一個活動的數(shù)據(jù)連接對象的方法,他接受一個數(shù)據(jù)庫連接字符串,如果調(diào)用者(上級)給他一個錯誤的連接字符串,這時Fun1創(chuàng)建不了連接對象,產(chǎn)生了一個創(chuàng)建不了連接對象的異常,那么這時他應該怎樣處理這個異常呢?彈出友好的消息框?說什么友好,Fun1根本就不知道是什么原因使他接收到了錯誤的連接字符串,彈一個“連接字符串有誤”,用戶肯定都有殺你的心,這個提示和用戶的業(yè)務邏輯有嘛關(guān)系!記錄錯誤日志,這個還行,但是記錄下來的文字無非就是“連接字符串有誤,連接字符串是:SQL……”,好點的話,從連接字符串中看出了問題,一般情況下還得根據(jù)代碼上下文去找問題原因。這個方式不是不行是不好。吞掉,哈哈開什么玩笑,你既創(chuàng)建不了連接,又不吱一聲,想讓調(diào)用者瘋了呀,這個肯定不行。做善后工作,行,確實應該清理一下現(xiàn)場,免得浪費資源,但是還是沒吱一聲,所以這個方式做的不徹底。沒招了,哈,其實上面的分析給我們指明了一條路,幫助我們祛除了錯誤的選擇,這條路就是向上匯報,或是不加任何出來代碼,或是記錄日志,做些善后,再重新將異常拋出。
那么什么時候就知道怎樣處理異常了,這就得看實際的情況和用戶的要求了,這句話等于沒說,就像其他的標題醒目但給出的結(jié)論卻模棱兩可文章一樣,哈哈,這里可以給幾個建議,
1,一般地,底層模塊或是方法中不要處理異常,
2,編寫公共模塊、DLL等是,不能采用彈出對話框等依賴于平臺,框架的方式處理異常,
3,編寫公共模塊、DLL等時,必須在使用文檔中注明每個方法屬性可能拋出的異常。
4,永遠不要寫 try 這樣的語句。
{ } catch(Exception) { o nothing } 自定義異常。明白了異常的原理和機制后,就可以自己定義異常了,這樣的實踐往往在編寫控件、公共模塊、DLL等的時候,用錯誤編號在網(wǎng)上搜索一下,能找出一大堆關(guān)于錯誤代碼的描述。其中大多數(shù)是M(icro)S(oft)制定的,MS 從操作系統(tǒng)到各種各樣的框架都有對各種異常的編號,對每種異常做出了詳細的定義,如果你還用過像Spread等商業(yè)控件,也可以看到他里邊的各種各樣的異常定義,也就是說我們自己也可以定義異常,在必要的時候,這樣就可以讓自己寫的模塊也加入到訓練有素的員工隊伍中了。至于如何定義異常,具體的編成語言有具體的做法,比如C#中指定一異常一個從Exception繼承來的類,VB中異常是個全局變量等等,參見感興趣語言的語法指南就可以了。
對異常的重新認識,一直以來許多人都認為異常是非常可怕的,可惡的,她是錯誤的化身,她有惱人的彈出對話框,弄得用戶跟兇煞惡神似的哈哈,其實這些都是誤解,異常一直默默地忠實的報告著程序中出現(xiàn)的嚴重的不可回避的問題,她為了程序、系統(tǒng)的正確性、嚴謹性呼喚你,希望你重視這些問題,希望你用智慧解決這些問題,她是多么的可愛,又是多么的高尚,從來沒有因為對她的誤解而放棄自己的使命……異常很重要,我們更好學會如何去使用她。