PO Wyjątki c.d.

<<< Powrót do przedmiotu Programowanie obiektowe

Zwalnianie zasobów

W Javie programista nie musi martwić się o rezerwowanie i zwalnianie pamięci. Odpowiada za to odśmiecacz. 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 możliwość wystąpienia wyjątku - jak nie trudno sobie wyobrazić - wcale nie ułatwia tego zadania. Niestety, 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ędzyczasie wykonywane są niebezpieczne operacje. Wobec tego w każdym bloku 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 zadbać o zwolnienie naszego zasobu zanim je ponownie zgłosimy.

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. Trzeba pamiętać o wszystkich możliwościach opuszczenia bloku try. Zwolnienie zasobów może być np. konieczne przed każdym 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ę przecież zdarzyć, że przez cały czas działania programu pamięci nie brakowało. Java oferuje inny mechanizm rekompensujący brak destruktora.

Blok finally

Do instrukcji try można dodać blok finally. Zawarty w nim 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. Blok finally jest doskonałym miejscem na zwalnianie wszelkiego rodzaju zasobów. Umieszcza się go bezpośrednio po ostatnim bloku 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
  //tu zwalniamy zasoby
}

Można też użyć samego bloku 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
  //tu zwalniamy zasoby
}

Jeżeli w bloku try nie wystąpił wyjątek, kod z bloku finally wykonywany jest bezpośrednio po jego zakończeniu. Jeżeli wyjątek wystąpił, ale nie pasuje do żadnego bloku catch lub nie umieszczono żadnego bloku catch, kod z bloku 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ący blok catch, to kod z bloku 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 tym bloku 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 statycznej 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. 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ź() z samochodów obu typów deklarują jedynie 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ź() {} //nie może deklarować wyjątków, bo
                                    //jedź() z Samochód i z 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 konstruktor nadklasy A użyć oraz jakie parametry przekazać, wskazuje się przy pomocy odwołania do superna początku konstruktora podklasy (jeżeli nie wskazano żadnego, to używany jest bezparametrowy). Dopiero po zakończeniu konstruktora z części ogólnej (A) inicjalizowana jest część szczegółowa (B) – 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ć i jaki parametr mu przekazać. 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 (pierwszą instrukcją byłoby wtedy try-catch, a nie odwołanie do super). Jeśli się nad tym zastanowić, obsługiwanie tych wyjątków nie ma sensu, skoro nie da się powtórzyć inicjalizacji części ogólnej. Wobec tego każdy błąd przy inicjalizacji części ogólnej uniemożliwia utworzenie egzemplarza i 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

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 było sprawdzać, jaki był efekt, są trudne do zrozumienia i mniej efektywne. Takie podejście do obsługi sytuacji wyjątkowych zniechęcało programistów do ich wykrywania i korygowania. Dzięki obsłudze błędów z całego bloku instrukcji, ilość kodu koniecznego do obsługi sytuacji wyjątkowych ulega ograniczeniu.

Co więcej, mechanizm obsługi wyjątków pozwala przenieść kod obsługi sytuacji wyjątkowej z dala od miejsca jej wykrycia. Zgłoszenie wyjątku przerywa normalny przepływ sterowania i rozpoczyna rozwijanie stosu wywołań, aż do napotkania kodu obsługującego ten typ wyjątku. Dzięki temu, jeżeli w danym miejscu nie wiadomo jak zareagować na dany wyjątek, po prostu się go ignoruje i obsługuje gdzie indziej. Zebranie i przeniesienie w dogodne miejsce kodu radzącego sobie z sytuacjami wyjątkowymi sprawia, że 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. Twierdzą, że podczas rozwijania i wprowadzania zmian do dużych systemów konieczność specyfikowania wyjątków może przysporzyć problemów. Co gorsza wiele osób zapomina o możliwości przepuszczenia wyjątku dalej i tylko dlatego żeby zadowolić kompilator wyłapuje wszystkie wyjątki, a kod obsługi tych, z którymi nie wie, co zrobić pozostawia pusty. 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 w deklaracjach metod. Niezależ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żesz dołączyć jako przyczynę do nowego egzemplarza RuntimeException. Możesz też rozszerzyć tą klasę i zupełnie zrezygnować z pomocy kompilatora.