Construiți încercați

* - puteți folosi un fir separat (System.err) pentru a afișa erori.

Java necesită procesarea aproape a tuturor excepțiilor (excepție), în conformitate cu această regulă, nu sunt mostenite excepții de la RuntimeException (eroare de execuție). În alte cazuri, va trebui să alegeți: să gestionați eroarea la fața locului. sau trimiteți eroarea la un nivel mai înalt (pentru această utilizare aruncați o nouă Excepție ()).

* - nu este necesar să interceptezi

De ce este rău să interceptați dintr-o dată prin Excepție, trecând de la Excepția mea

Răspunsul este destul de simplu și evident. De fiecare dată, interceptarea unei erori ar trebui înțeleasă sau, mai degrabă, trebuie să știți dacă puteți intercepta și procesa corect eroarea. Dacă în momentul scrierii acestei clase nu puteți face acest lucru, atunci ar trebui să treceți această eroare la un nivel mai înalt.

Câteva cuvinte despre cuvânt

Blocul final este aranjat în așa fel încât să fie executat în orice caz. Vă rog să fiți atenți la aceste cuvinte, în ele cel mai interesant este ascuns:

Ce se întoarce la getNumber ()?

Cel mai bun mod de a trata excepțiile

Dacă excepția poate fi procesată corect, atunci trebuie capturată, în caz contrar, aceasta trebuie trimisă mai departe (adică nu merită capturarea (Excepție e)).

Cum să rezolvați diferite excepții în moduri diferite?

Este suficient să alocați mai multe clicuri consecutive, este important să nu rupeți ierarhia, altfel excepția poate fi procesată mai devreme decât aveți nevoie (într-un alt bloc de captură).

Este necesar să se verifice toate excepțiile?

Nu, există excepții "neconfirmabile" pe care nu trebuie să le procesați, de exemplu: NullPointerException (pointer null) nu necesită crearea unui bloc try / catch. În schema de mai sus, excepțiile "neconfirmabile" sunt indicate în verde.

Poate constructorul "apela" excepții?

Desigur, puteți, designerul este aceeași metodă ca oricine altcineva.

Articole similare

Pagina anterioară

Pagina următoare