java中throw拋出的一些異常，程序不進(jìn)行處理程序編譯也不會(huì)錯(cuò)誤？不，拋出異常的目的是在某些條件不滿足時(shí)終止程序，但您也可以選擇捕獲處理，捕獲后程序不會(huì)終止。但是為什么一些系統(tǒng)化的方法必須讓你捕獲

java中throw拋出的一些異常，程序不進(jìn)行處理程序編譯也不會(huì)錯(cuò)誤？

不，拋出異常的目的是在某些條件不滿足時(shí)終止程序，但您也可以選擇捕獲處理，捕獲后程序不會(huì)終止。但是為什么一些系統(tǒng)化的方法必須讓你捕獲？這是因?yàn)榉椒ㄊ怯胻hrows關(guān)鍵字聲明的。它的功能是將throw顯示的異常交給調(diào)用者處理。如果調(diào)用者不處理它，他就不會(huì)嘗試catch，然后編譯就會(huì)失敗。

編譯錯(cuò)誤和運(yùn)行時(shí)異常怎么區(qū)分？

編譯錯(cuò)誤通常是語(yǔ)法問(wèn)題。編譯錯(cuò)誤未運(yùn)行。它指的是程序運(yùn)行過(guò)程中的一個(gè)錯(cuò)誤。只能說(shuō)程序中有一定的邊界bug。編譯錯(cuò)誤通常指Java語(yǔ)法錯(cuò)誤。運(yùn)行錯(cuò)誤有兩種：錯(cuò)誤和異常有些異常是拋出但可以連續(xù)執(zhí)行的代碼，有些異常是不能連續(xù)執(zhí)行的代碼，如runtimeException、ClassCastException，那么，對(duì)編譯和運(yùn)行時(shí)最好的理解就是java1.5之后的泛型機(jī)制。在以前的版本中，如果沒(méi)有正確考慮，運(yùn)行時(shí)只會(huì)出現(xiàn)異?！，F(xiàn)在添加了generic，問(wèn)題將在編譯時(shí)暴露，這提高了代碼的安全性。

如果在寫C語(yǔ)言時(shí)，代碼沒(méi)錯(cuò)，但是結(jié)果總錯(cuò)是什么原因？

我想您要表達(dá)的是編譯時(shí)沒(méi)有錯(cuò)誤，但是結(jié)果是錯(cuò)誤的。我們應(yīng)該仔細(xì)找出原因。

根據(jù)我過(guò)去的經(jīng)驗(yàn)，有幾個(gè)原因。

1，內(nèi)存未釋放。

使用new和malloc分配內(nèi)存，并在最后釋放內(nèi)存。頻繁的調(diào)用會(huì)導(dǎo)致系統(tǒng)崩潰。

或者根本不使用new或malloc，使用內(nèi)存時(shí)發(fā)生異常。

2. 變量和地址使用錯(cuò)誤。

Char*P

Char CP

第一個(gè)P表示地址，該地址在程序中使用不正確。

3、畫筆CPEN、CStatic等未恢復(fù)

例如：oldpen=PDC-gtselectobject（&mè在結(jié)尾，沒(méi)有PDC-gtselectobject（oldpen）

會(huì)導(dǎo)致顏色混淆。

4. 中斷或回調(diào)函數(shù)使用不當(dāng)。

5。C語(yǔ)言對(duì)變量類型有嚴(yán)格的要求。有符號(hào)和無(wú)符號(hào)有很大區(qū)別。詳細(xì)檢查功能原型。

6. 最后，對(duì)算法和框圖進(jìn)行了驗(yàn)證。基本算法是否錯(cuò)誤。這很難做到。相信大家都很自負(fù)，堅(jiān)信算法是對(duì)的。檢查數(shù)學(xué)算法是否與程序算法一致。

7. 浮點(diǎn)運(yùn)算。我們相信1.0+1.0=2.0是毫無(wú)疑問(wèn)的。如果double和其他變量之間的轉(zhuǎn)換出現(xiàn)問(wèn)題，可能是由于以下原因造成的：

1.0+1.0=1.99999999