PO Wyjątki c.d.

Zwalnianie zasobów

W Javie programista nie musi martwić się o rezerwowanie i zwalnianie pamięci. Odbywa się to automatycznie. Mimo to o rezerwowanie i zwalnianie wielu innych zasobów trzeba dbać samemu. Najbardziej typowe przykłady to otwarte pliki, połączenia sieciowe oraz połączenia z bazą danych. Pilnowanie aby wszystkie zasoby zostały w końcu zwolnione wymaga wiele dyscypliny, a jak nie trudno sobie wyobrazić możliwość wystąpienia wyjątku wcale nie ułatwia tego zadania. Wyjątki występujące w trakcie czytania z pliku, przesyłania danych przez sieć lub korzystania z bazy danych wcale nie są czymś nadzwyczajnym.

W poniższym przykładzie używamy hipotetycznego zasobu, który najpierw trzeba zarezerwować a potem zwolnić. W między czasie wykonywane są niebezpieczne operacje. Wobec tego w każdej klauzuli catch musimy pilnować, żeby mimo wystąpienia wyjątku zasób został zwolniony. Co więcej mimo, że w tej instrukcji try-catch chcieliśmy obsługiwać tylko dwa wyjątki IOException oraz InnyMożliwyWyjątek, wyłapujemy również wszystkie inne, żeby zanim je ponownie zgłosimy zadbać o zwolnienie naszego zasobu.

import java.io.IOException;

class InnyMożliwyWyjątek extends Exception {}

class Zasób1 {
  void zarezerwuj() {}
  void używaj() throws IOException {}
  void innaNiebezpiecznaOperacja() throws InnyMożliwyWyjątek {}
  void zwolnij() {}
}

public class ZwalnianieZasobów1 {
  public static void main(String[] args) throws Exception {
    Zasób1 z = new Zasób1();
    try {
      z.zarezerwuj();

      //tu jest niebezpieczny kod
      z.używaj();
      z.innaNiebezpiecznaOperacja();
      //...

      //zwalnianie zasobów
      z.zwolnij();
    } catch (IOException e) {
      //obsługa wyjątku IOException

      //zwalnianie zasobów
      z.zwolnij();
    } catch (InnyMożliwyWyjątek w) {
      //obsługa wyjątku InnyMożliwyWyjątek

      //zwalnianie zasobów
      z.zwolnij();
    } catch (Exception e) {
      //innych wyjątków nie obsługujemy,
      //ale przechwytujemy je na chwilę, żeby zwolnić zasoby

      //zwalnianie zasobów
      z.zwolnij();
      throw e;
    }
  }
}

Takie rozwiązanie jest pracochłonne i wymaga dużo uwagi. Kod wykonujący operacje na zasobie może być skomplikowany. Zwalnianie zasobów może być konieczne w kilku miejscach, np. wszędzie przed wystąpieniem instrukcji return kończącej wykonanie metody, która zawiera rozważaną przez nas instrukcję try-catch oraz (jeżeli instrukcja ta była w pętli) wszędzie przed wystąpieniem instrukcji break i continue. Oba te przypadki pokazuje poniższy przykład.

import java.io.IOException;

class InnyMożliwyWyjątek extends Exception {}

class Zasób2 {
  Zasób2(int i) {
    //...
  }
  void zarezerwuj() {}
  void używaj() throws IOException {}
  void innaNiebezpiecznaOperacja() throws InnyMożliwyWyjątek {}
  void zwolnij() {}
}

public class ZwalnianieZasobów2 {
  public static void main(String[] args) throws Exception {
    for (int i = 0; i < 10; i++) {
      Zasób2 z = new Zasób2(i);
      try {
        z.zarezerwuj();

        //tu jest niebezpieczny kod
        z.używaj();
        z.innaNiebezpiecznaOperacja();
        //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
        //trzeba zwolnić zasób, bo kończy się obrót pętli
        if (i == 3) continue;
        //trzeba zwolnić zasób, bo kończy się cała metoda
        if (i == 8) return;
        //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
        //...

        //zwalnianie zasobów
        z.zwolnij();
      } catch (IOException e) {
        //obsługa wyjątku IOException

        //zwalnianie zasobów
        z.zwolnij();
      } catch (InnyMożliwyWyjątek w) {
        //obsługa wyjątku InnyMożliwyWyjątek

        //zwalnianie zasobów
        z.zwolnij();
      } catch (Exception e) {
        //innych wyjątków nie obsługujemy,
        //ale przechwytujemy je na chwilę, żeby zwolnić zasoby

        //zwalnianie zasobów
        z.zwolnij();
        throw e;
      }
    }
  }
}

W niektórych językach programowania, np. w C++, aby ułatwić zadanie, do obiektów dodawana jest specjalna metoda tak zwany destruktor, która jest wykonywana w chwili niszczenia obiektu. Jest to doskonałe miejsce na umieszczenie kodu zwalniającego zasoby. W C++ destruktory są bardzo często używane, gdyż programista jest odpowiedzialny również za zwalnianie pamięci. W Javie zajmuje sie tym odśmiecacz, który wprawdzie wywołuje na każdym obiekcie metodę finalize() (można by próbować zwalniać w niej zasoby), ale nie ma gwarancji, że obiekty zostaną poddane procesowi odśmiecania. Może się zdarzyć, że przez cały czas działania programu pamięci nie brakowało. Java oferuje inny mechanizm rekompensujący brak destruktora.

Klazula finally

Do instrukcji try można dodać klauzulę finally. Zawarty w niej kod jest wykonywany zawsze, niezależnie od tego czy w bloku try jest zgłaszany wyjątek czy nie (i niezależnie od tego czy try kończy się normalnie, z powodu return, czy z powodu break lub continue). Klauzula finally jest doskonałym miejscem na zwalnianie wszelkiego rodzaju zasobów. Umieszcza się ją bezpośrednio po ostatniej klauzuli catch.

try {
  //kod który może zgłosić wyjątki
} catch (Typ1 w) {
  //obsługa wyjątków Typ1
} catch (Typ2 w) {
  //obsługa wyjątków Typ2
} catch (Typ3 w) {
  //obsługa wyjątków Typ3
} finally {
  //kod wykonywany niezależnie od wystąpienia wyjątku
}

Można też użyć samej klauzuli finally i nie obsługiwać żadnych wyjątków.

try {
  //kod który może zgłosić wyjątki
} finally {
  //kod wykonywany niezależnie od wystąpienia wyjątku
}

Jeżeli w bloku try nie wystąpił wyjątek, kod z klauzuli finally wykonywany jest bezpośrednio po jego zakończeniu. Jeżeli wyjątek wystąpił, ale nie pasuje do żadnej klauzuli catch lub żadna klauzula catch nie została użyta, kod z klauzuli finally wykonywany jest bezpośrednio po wystąpieniu wyjątku, a przed rozpoczęciem rozwijania stosu wywołań w poszukiwaniu innej instrukcji try-catch, która mogłaby ten wyjątek obsłużyć. W końcu, jeżeli wyjątek wystąpił i jest pasująca klauzula catch, to kod z klauzuli finally wykonywany jest bezpośrednio po zakończeniu obsługi wyjątku. Opisaną kolejność obrazuje poniższy przykład.

public class TestFinally {
  public static void main(String[] args) {
    try {
      System.out.println("Zewnętrzne try");
      try {
        System.out.println("Pierwsze wewnętrzne try");
      } finally {
        System.out.println("Pierwsze wewnętrzne finally");
      }
      try {
        System.out.println("Drugie wewnętrzne try");
        throw new Exception();
      } finally {
        System.out.println("Drugie wewnętrzne finally");
      }
    } catch (Exception e) {
      System.out.println("Obsługa wyjątku");
    } finally {
      System.out.println("Zewnętrzne finally");
    }
  }
}

W wyniku działania tego programu na standardowym wyjściu zostanie wyprodukowany następujący wynik.

Zewnętrzne try
Pierwsze wewnętrzne try
Pierwsze wewnętrzne finally
Drugie wewnętrzne try
Drugie wewnętrzne finally
Obsługa wyjątku
Zewnętrzne finally

Zaginięcie wyjątku

Z użyciem finally wiąże się jeden mankament. Kod zawarty w tej klauzuli w żadnym wypadku nie powinien zgłaszać wyjątku. Jeżeli wyjątek zgłaszany w bloku try nie został obsłużony, a w finally również zgłaszany jest wyjątek, to wyjątek z bloku try zaginie. Tak właśnie dzieje się w poniższym przykładzie.

class WażnyWyjątek extends Exception {}
class JakiśInnyWyjątek extends Exception {}
class NieważnyWyjątek extends Exception {} 

public class ZaginięcieWyjątku {
  static void niebezpiecznyKod() throws WażnyWyjątek, JakiśInnyWyjątek {
    throw new WażnyWyjątek();
  }
  public static void main(String[] args) throws Exception {
    try {
      //tego wyjątku nie wolno przegapić
      niebezpiecznyKod();
    } catch (JakiśInnyWyjątek w) {
      //obsługa jakiegoś innego wyjątku
    } finally {
      //zwalnianie zasobów
      throw new NieważnyWyjątek();
    }
  }
}

Wyjątki, a tworzenie i inicjalizacja obiektów

Tworzenie i inicjalizacja obiektów następuje w chwili użycia słowa kluczowego new i wskazaniu po nim konstruktora. Najpierw, jeżeli jeszcze to nie było zrobione, maszyna wirtualna wczytuje definicję klasy i wykonuje jej inicjalizację statyczną. Podczas inicjalizacji statycznej nie mogą być zgłaszane żadne wyjątki. Dotyczy to zarówno inicjalizacji statycznych atrybutów jak i wykonywania kodu z bloków inicjalizacji statycznej (static { ... }). Gdy inicjalizacja statyczna się zakończy, bądź nie jest konieczna, bo maszyna wirtualna używała już tej klasy, następuje inicjalizacja egzemplarza i wykonywany jest wskazany konstruktor. Każdy wyjątek, który może być zgłoszony w trakcie inicjalizacji atrybutów egzemplarza lub podczas wykonywania kodu z bloków inicjalizacji ({ ... }) musi być wymieniony w klauzulach throws wszystkich konstruktorów. Dodatkowo każdy konstruktor może jeszcze zgłaszać dalsze wyjątki.

class WyjA extends Exception {};
class WyjB extends Exception {};
class WyjC extends Exception {};
class WyjD extends Exception {};
class WyjE extends Exception {};

public class WyjątkiAInicjalizacja {
  static void możeZgłosićWyjątek() throws WyjA {}

  //wyjątki z bloków inicjalizacji muszą być wymienione w klauzulach throws wszystkich konstruktorów
  {
    możeZgłosićWyjątek();
  }
 
  //podczas inicjalizacji składowych statycznych klasy nie można zgłaszać wyjątków
  // static { 
  //   możeZgłosićWyjątek();
  // }
 
  static int statyczna() throws WyjB {
    return 1;
  }
 
  int normalna() throws WyjC {
    return 2;
  }
 
  //wyjątki, które mogą być zgłoszone podczas inicjalizacji atrybutów egzemplarza
  //muszą być wymienione w klauzulach throws wszystkich konstruktorów
  int i = normalna();
  int j = statyczna();
 
  //podczas inicjalizacji składowych statycznych klasy nie można zgłaszać wyjątków
  // static k = statyczna();
 
  WyjątkiAInicjalizacja() throws WyjA, WyjB, WyjC {
  }

  WyjątkiAInicjalizacja(int i) throws WyjA, WyjB, WyjC, WyjD {
    throw new WyjD();
  }

  WyjątkiAInicjalizacja(String s) throws WyjA, WyjB, WyjC, WyjE {
    throw new WyjE();
  }
}

Wyjątki, a rozszerzanie obiektów

To jakie wyjątki mogą zgłaszać metody nadklasy ma wpływ na to jakie wyjątki mogą zgłaszać metody podklasy. Warto rozważyć trzy przypadki: przedefiniowane metody, nowe metody i konstruktory.

Przedefiniowane metody

Obiekty podklasy muszą się dawać używać w miejsce obiektów nadklasy. W przypadku metod oznacza to, że metody podklasy muszą być nadzbiorem metod z nadklasy. Tak samo jest w przypadku atrybutów. W przypadku wyjątków zgłaszanych przez każdą z metod jest dokładnie odwrotnie. Te zgłaszane przez (bardziej szczegółowe) metody z podklasy muszą być podzbiorem tych zgłaszanych przez (bardziej ogólne) metody z nadklasy. Jest tak dlatego, że żadna uszczegółowiona wersja metody nie może zgłaszać wyjątków, na które nie byłby przygotowany kod zakładający użycie ogólnej metody z nadklasy. Jeżeli w nadklasie metoda m() zdeklaruje, że zgłasza wyjątki A i B, to jej uszczegółowiona wersja w podklasie może zgłaszać wyjątki A i B lub sam wyjątek A lub sam wyjątek B lub może nie zgłaszać żadnych wyjątków lub dowolne wyjątki, które są podklasami A albo B. W poniższym przykładzie metody jedź() obu rodzai samochodu deklarują jedynie wyjątki uszczegółowione wersje wyjątku deklarowanego przez swoją nadklasę.

class BrakPaliwa extends Exception {}
class BrakBenzyny extends BrakPaliwa {}
class BrakGazu extends BrakPaliwa {}

abstract class Samochód {
  abstract void jedź() throws BrakPaliwa;
}

class SamochódNaBenzynę extends Samochód {
  void jedź() throws BrakBenzyny {}
}

class SamochódONapędzieHybrydowym extends Samochód {
  void jedź() throws BrakBenzyny, BrakGazu {}
}

Te same ograniczenia co przy przesłanianiu metod dotyczą implementowania metod wymienionych w interfejsach. Jeżeli, któraś metoda wymieniana jest naraz w kilku implementowanych interfejsach i/lub nadklasie, deklarowane przez nią wyjątki muszą należeć do przecięcia zbiorów z poszczególnych deklaracji. Często to przecięcie będzie zbiorem pustym. W poniższym przykładzie metoda jedź() w klasie PerpetuumMobile nie może deklarować żadnych wyjątków, bo jedź() z klasy Samochód i jeźdź() z interfejsu WehikułCzasu nie deklarują wspólnych wyjątków.

class BłądContinuum extends Exception {}
class ŁamiePrawaFizyki extends Exception {}

interface WehikułCzasu {
  void jedź() throws ŁamiePrawaFizyki;
  void przenieśSięWCzasie() throws BłądContinuum;
}

class PerpetuumMobile extends Samochód implements WehikułCzasu {
  public void jedź() {} //jedź() z Samochód i WehikułCzasu nie mają wspólnych wyjątków
  public void przenieśSięWCzasie() throws BłądContinuum {} 
}

Nowe metody

Nowych (nie występujących w nadklasie) metod podklasy nie dotyczą żadne ograniczenia. Mogą zgłaszać dowolne wyjątki lub nie zgłaszać ich wcale.

Konstruktory

Przypomnijmy, że podczas tworzenia obiektu najpierw odbywa się pełna inicjalizacja części ogólnej, w tym wywoływany jest któryś jej konstruktor. Jeżeli na przykład klasa B rozszerza klasę A, to w chwili tworzenia nowego egzemplarza B najpierw następuje pełna inicjalizacja jego części odziedziczonej po klasie A. Ta inicjalizacja kończy się wywoływaniem konstruktora z klasy A, który wskazano na początku używanego konstruktora klasy B (jeżeli nie wskazano żadnego to używany jest bezparametrowy). Dopiero po zakończeniu konstruktora z części ogólnej inicjalizowana jest część szczegółowa – najpierw atrybuty i bloki inicjalizacji, a dopiero na końcu konstruktor. Konstruktor nadklasy nie jest więc wykonywany na początku konstruktora podklasy, ale tylko wskazuje się tam którego konstruktora użyć. To tylko taka notacja. Nie można tego konstruktora otoczyć instrukcją try-catch żeby obsłużyć wyjątki, które wystąpiły podczas inicjalizacji części ogólnej. Jeśli się nad tym zastanowić obsługiwanie tych wyjątków nie ma sensu skoro nie da się powtórnie wymusić inicjalizacji części ogólnej. Wobec tego konstruktory podklasy muszą co najmniej deklarować wszystkie wyjątki, które deklaruje wskazywany przez nie konstruktor nadklasy. Nie ma natomiast żadnego powodu żeby nie miały deklarować więcej wyjątków. W poniższym przykładzie wszystkie konstruktory podklasy SamochódTerenowyONapędzieHybrydowym muszą deklarować wyjątek BrakGotówki, bo jest on deklarowany przez jedyny konstruktor nadklasy SamochódTerenowy.

class BrakGotówki extends Exception {}
class NiedostępnyWSprzedaży extends Exception {}

class SamochódTerenowy extends Samochód {
  SamochódTerenowy() throws BrakGotówki {}
  void jedź() throws BrakPaliwa {}
}

class SamochódTerenowyONapędzieHybrydowym extends Samochód {
  SamochódTerenowyONapędzieHybrydowym() throws BrakGotówki, NiedostępnyWSprzedaży {
    //jeżeli nie wskazujemy konstruktora nadklasy, zostanie użyty bezparametrowy
  }
  SamochódTerenowyONapędzieHybrydowym(String s) throws BrakGotówki, NiedostępnyWSprzedaży {
    //tu tylko wskazujemy, który konstruktor nadklasy wybrać
    //zostanie on wykonany wcześniej, więc nie możemy go otoczyć instrukcją try-catch
    super();
    throw new NiedostępnyWSprzedaży();
  }
  void jedź() throws BrakBenzyny, BrakGazu {}
}

Podsumowanie

Mechanizm obsługi wyjątków pozwala przerwać normalny przepływ starowania w programie i przekazać sterowanie do miejsca, gdzie jest możliwe zareagowanie na sytuację wyjątkową. Wyjątki zostały wprowadzone do języków programowania, ponieważ obsługa wszystkich sytuacji wyjątkowych mogących wystąpić w trakcie wywoływania każdej kolejnej metody jest zbyt uciążliwa. Programy, w których po każdym wywołaniu metody trzeba sprawdzać jaki był efekt, są trudne do zrozumienia i mniej efektywne. Takie sposób obsługi sytuacji wyjątkowych skutkuje tym, że programiści unikają ich zgłaszania i obsługi. Wyjątki pozwalają ograniczyć ilość kodu koniecznego do obsługi sytuacji wyjątkowych dzięki obsłudze błędów bloku instrukcji. Umożliwiają również przeniesienie kodu obsługi z dala od miejsca wystąpienia wyjątku. Jeżeli nie wiadomo jak zareagować na dany wyjątek, najlepiej go po prostu w tym miejscu nie łapać. Dzięki zebraniu i przeniesieniu w dogodnie miejsce kodu radzącego sobie z sytuacjami wyjątkowymi reszta programu staje się bardziej przejrzysta i spójna.

W Javie kompilator pilnuje, aby programista był świadom, wyjątków które mogą się pojawić. Jeżeli nie chce ich obsługiwać, powinny być wymienione w klauzuli throws. Wymienienie wyjątku w klauzuli throws może oznaczać dwie rzeczy: że gdzieś indziej należy się zająć danym wyjątkiem, bo tu jest zgłaszany albo że gdzieś indziej należy się zająć tym wyjątkiem, bo tu nie wiadomo co z nim zrobić. W obu przypadkach jest to świadoma decyzja. Żadne wyjątki nie zostaną przeoczone. Takie podejście ma swoje zalety. Nie jest to jednak standard. Niektórzy uważają, że specyfikowanie wyjątków, które mogą być zgłoszone wygląda tak zachęcająco, bo używane przykłady są bardzo proste. Podczas rozwijania i wprowadzania zmian do dużych systemów konieczność specyfikowania wyjątków przysporzyć wielu problemów. Co gorsza wiele osób zapomina o drugiej możliwości i tylko dlatego żeby zadowolić kompilator wyłapuje, a następnie ignoruje wyjątki, z którymi w danym kontekście nie wiadomo co zrobić. Jest to przykład na to, że żaden mechanizm językowy nie zmusi programistów do pisania dobrych programów, a jedynie może to ułatwić. W innych obiektowych językach programowania jak C# nie wymienia się zgłaszanych wyjątków. Nie zależnie od tego, które podejście uważasz za lepsze, pamiętaj że w Javie jest wybór. Kompilator nie wymusza specyfikowania wyjątków RuntimeException. Wyjątki, których nie chcesz dopisywać w klauzulach throws może dołączyć jako przyczynę do nowego egzemplarza RuntimeException. Możesz też rozszerzyć tą klasę i zupełnie zrezygnować z pomocy kompilatora.