Mga karaniwang error sa paghawak ng exception

Ang isang pagbubukod ay isang pagkagambala sa normal na daloy ng pagpapatupad ng isang Java (o anumang iba pang) program. Ang paglabag na ito ay maaaring mangyari dahil sa isang paglabag sa pag-access sa memorya, paghahati sa pamamagitan ng zero, problema sa pagsisimula, pagpapatupad ng isang ilegal na pagtuturo, o anumang iba pang nakamamatay na error. Ang Java ay may kakayahang pangasiwaan ang lahat ng gayong hindi gustong mga sitwasyon nang maganda, ngunit pagdating sa paggamit ng mga tampok na ito ng Java ng mga developer, maraming problema ang maaaring lumitaw. Sa artikulong ito, hindi ko tatalakayin kung paano gumagana ang Exception Handling sa Java. Ipinapalagay ko na ang mambabasa ay pamilyar na sa exception hierarchy, checked exceptions , unchecked exceptions , at runtime exceptions . Dito ay tatalakayin natin ang mga pinakakaraniwang pagkakamali na dapat mong iwasan.

Mga Stakeholder sa Exceptions

Sa tuwing ang thread ng execution ay naaantala, ang impormasyon tungkol dito ay dapat ibalik sa program executor. Maaaring magsimula ang thread na ito mula sa screen, mula sa isang batch na gawain, o sa anumang iba pang paraan. Ang lahat ng mga trigger na ito ay naghihintay para sa ilang uri ng paglabag sa daloy upang magpadala ng mensahe ng isang partikular na format. Maaaring dahan-dahang ipaalam sa amin ng trigger na nakabatay sa screen na may ilang teknikal na isyu at dapat kaming makipag-ugnayan sa suporta para sa tulong at payo. Maaaring asahan ng mga batch na proseso o standalone na Java program ang ulat ng error na lalabas sa anyo ng ilang uri ng log na ganap na hindi maintindihan ng end user. Ngunit ang mga negosyante ay kailangang makatanggap ng mga mensahe sa isang wikang naiintindihan nila. Ang kinatatakutang NullPointerException sa isipan ng mga user ay lubhang nakakainis. Minsan ang mga error na ito ay bunga ng maling paggamit ng program, ngunit kung minsan ang mga ito ay mga problema na nangangailangan ng pagwawasto. Ang pangalawang mahalagang stakeholder ay ang taong haharapin ang mga problemang itinaas ng mga eksepsiyon. Hindi maobserbahan ng taong ito ang aktwal na pagpapatupad ng programa kapag nangyari ang pagbubukod. Aasa ito sa dalawang bagay - una, impormasyong ibibigay ng user na nagkakaroon ng problema, at pangalawa, isang uri ng log na nabuo kapag may nangyaring exception. Bilang karagdagan, ang taong susuriin ang problema ay hindi ang parehong tao na sumulat ng programa, at samakatuwid ang program developer ay dapat magbigay ng sapat na impormasyon para sa pagsusuri. Ang tanging paraan ng komunikasyon sa pagitan ng developer ng program at debugger nito ay isang log. Gayundin, minsan dahil sa mga kadahilanang pangseguridad, ang log log kung minsan ay maaaring hindi naglalaman ng lahat ng aktwal na detalye ng pagpapatupad ng programa kapag naganap ang pagbubukod. Tingnan natin ang mga posibleng error sa paghawak ng exception. Ang ilan sa kanila ay mukhang bobo, ngunit may mga tao. na hindi binibigyang pansin ang mga ito hanggang ang mga pagkakamaling ito ay humantong sa mga problema.

Walang laman ang exception block

Ito ay isa sa mga pinaka-hindi gustong mga error sa exception handling. Sa kasong ito, ang pagbubukod ay binabalewala lamang. Ang solusyon ay naglalaman ng walang anuman kundi isang linya ng komento upang iwanan ang pagbubukod. try{ }catch(SQLException sqe){ // do nothing } Sa ilang mga bihirang kaso, tulad ng sa huling bloke kapag ang database ay isinara, ang mga pagbubukod ay maaaring itapon. Sa kasong ito maaari silang hindi papansinin. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Maling generalization ng exception message

Ang puntong ito ay subjective. Pagkatapos makuha ang exception, maaari mo itong iulat sa end user sa anyo ng isang friendly na mensahe. Posible na ang mga detalye ng orihinal na mensahe ay mawawala kapag ang orihinal na mga mensahe ay na-convert sa isang pangkalahatang mensahe. Dapat ihatid ng mensahe ang wastong impormasyon sa end user upang kapag nakikipag-ugnayan sa team ng suporta, kailangan lang ng user na mag-log in sa naaangkop na log upang ibigay ang impormasyon. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } Sa isang multi-tier na application, ang bawat layer ay nakakakuha ng mga exception at naghagis ng bagong uri ng exception. Minsan talagang kinakailangan na maglagay ng exception ng isang partikular na uri: - Data Access Layer -> lumilikha ng DataAccessException - Business Implementation Layer -> lumilikha ng BusinessException - Application Service Layer -> lumilikha ng ApplicationServiceException Mukhang lohikal ang lahat, hindi ba? Dito maaaring kailanganin nating pumili sa pagitan ng ApplicationServiceException at BusinessException dahil pareho silang maaaring kumatawan sa parehong impormasyon. Ang isa sa mga exception na conversion na ito ay tila hindi kailangan.

Sinisira ang klase ng StackTrace

Sa panahon ng proseso ng pagbabago ng exception sa isang bagong espesyal na uri, maaaring mawala ang stack trace, na ginagawang bangungot ang pagsubaybay sa aktwal na dahilan ng exception. Sa code sa ibaba makikita mo kung paano itinapon ang isang bagong exception nang hindi natatanggap ang anumang impormasyon mula sa orihinal na exception. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Pag-overwrite sa dahilan ng pagbubukod

Ang bawat mensahe ng exception ay naglalaman ng impormasyon tungkol sa dahilan ng exception. Gayunpaman, kapag ang isang bagong pagbubukod ay nilikha, ang impormasyon tungkol sa luma ay maaaring permanenteng matanggal. Ito ay katulad ng halimbawa sa itaas kung saan maaaring alisin ang StackTrace dahil sa isang bagong exception na itinapon.

Walang paghahanap ng mga partikular na pagbubukod

Minsan gusto ng mga developer na maglaro nang ligtas kapag humahawak ng mga pagbubukod. Minsan ito ay madaling gawin. Ngunit ang pagkuha ng java.lang.Exception sa halip na isang partikular na exception ay hindi katanggap-tanggap. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Hindi kinakailangang catch at throw

Mahuli ang mga exception kung gusto mong i-convert ang mga ito sa ibang uri, o kung makakatulong ito sa iyong magdagdag ng ilang impormasyon sa exception message sa end user o analyst. Kung hindi, itapon na lang ang mga ito sa signature ng pamamaraan (gamit ang mga throws) sa halip na hulihin ang mga ito.

Pagkuha ng RuntimeException

Inirerekumenda ko ang pag-iwas sa paghuli sa RuntimeException. Sa halip, mas mahusay na mahuli ang mga partikular na eksepsiyon at gamutin ang mga ito.

Paghahanap ng mga walang check na exception

Ito ay isang kontrobersyal na paksa kung kukuha ng hindi nasuri na mga pagbubukod o hindi. Maaaring ang NullPointerException at ArrayIndexOutOfBound ang pinakamahusay na mga halimbawa ng mga hindi naka-check na exception. Sa halip na mahuli ang mga pagbubukod na ito, maaari mong baguhin ang iyong code upang mahawakan ang mga sitwasyong ito. Halimbawa, upang maiwasan ang NullPointerException, upang matiyak na ang lahat ng mga variable ay nasimulan, upang maiwasan ang mga pagbubukod ng ArrayIndexOutOfBound, upang tukuyin ang isang array ng tamang haba, atbp.

Mga isyung nauugnay sa pag-log ng exception

Tutulungan ng magasin ang pangalawang interesadong tao, iyon ay, ang taong nagsusuri sa problema. Minsan ang isang developer ay lumalampas sa mga log file at ang mga log ay nilikha sa bawat antas ng application. Dapat itala ng log ang pagbubukod sa antas kung saan ito nangyari. Mukhang pinakamainam na magpakita ng babala na may naganap na pagbubukod, na may panukalang ihinto o ipagpatuloy ang pagpapatupad ng programa, at mandatoryong pag-log ng exception sa log.

Pagbubukod sa kontrol ng daloy

Ang isang pagbubukod ay isang pagkagambala sa normal na daloy ng programa, na nangangahulugan na kailangan mong matakpan ang daloy na ito at ipaalam sa end user ang tungkol dito. Kung magdaragdag kami ng method call na isang alternatibong thread, hahantong ito sa malalaking problema sa pagpapanatili. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Ubiquitous na paggamit ng java.lang.Exception

Hindi rin magandang ideya na gumamit ng java.lang.Exception sa lahat ng dako para sa anumang exception. Sa halip, mas mainam na gumamit ng mga pagbubukod na partikular sa application, o ang pinakaangkop na karaniwang mga pagbubukod sa Java. Orihinal na artikulo: Mga Karaniwang Pagkakamali sa Paghawak ng Exception Isinalin at binibigkas ni: Ve4niY