Sobes.tech
Middle

Millist Java erandit ei saa töödelda?

sobes.tech AI

Vastus AI-lt

Viga.

Java jagab erandid (Throwable) kolme põhiliiki:

  1. Kontrollitud erandid (Checked Exceptions): Nõuavad kohustuslikku töötlemist või teavitamist meetodi signatuuris (throws).
  2. Kontrollimata erandid (Unchecked Exceptions, Runtime Exceptions): Ei nõua kohustuslikku töötlemist. Tavaliselt näitavad programmeerimise loogika vigu.
  3. Vead (Errors): Esindavad tõsiseid probleeme, mis on seotud Java virtuaalse masina või süsteemi ressurssidega. Nende töötlemine rakenduse tasandil ei ole võimalik, kuna need ei ole seotud koodi probleemidega.

Error näited:

  • OutOfMemoryError: Java virtuaalne masin ei suutnud mälu eraldada.
  • StackOverflowError: Pöörise üleküllus (liiga sügav rekursioon).
  • InternalError: Java Virtual Machine sisemine viga.

Error töötlemine try-catch-iga ei ole mõistlik, kuna need vead näitavad olekuid, millest rakendus tavaliselt edukalt taastuda ei suuda. Selle asemel lõpetab rakendus tavaliselt töö Error-i tekkimisel.

Tehniliselt on võimalik kirjutada catch (Error e), kuid sellist koodi peetakse halbaks praktikaks ega lahenda põhiküsimust.

try {
    // Kood, mis võib põhjustada OutOfMemoryError
    List<Object> list = new ArrayList<>();
    while (true) {
        list.add(new Object());
    }
} catch (OutOfMemoryError e) {
    // See plokk täidetakse, kuid te ei saa taastuda,
    // kuna süsteemil ei ole piisavalt mälu:
    System.err.println("Out of memory! Application will likely terminate.");
    // Järgmised toimingud siin on kas mõttetud või põhjustavad SecurityException-i
} catch (Exception e) {
    // Muude erandite töötlemine
    e.printStackTrace();
}

QA automatiseerimises, kui testi käigus tekib Error, näitab see tõenäoliselt probleemi testikeskkonnas, JVM-i konfiguratsioonis või tõsist viga rakenduses, mis põhjustas kriitilise tõrke, mitte oodatavat töötlevat erandit. Sellised stsenaariumid nõuavad põhjusliku analüüsi väljaspool testkoodi.