Programowanie w języku Java WYKŁAD

Transkrypt

1 Programowanie w języku Java WYKŁAD dr inż. Piotr Zabawa Certyfikowany Konsultant IBM/Rational pzabawa@pk.edu.pl www:

2 WYKŁAD 7 Wyjątki

3 Częstym problemem jest optymistyczne podejście do wytwarzania oprogramowania. Cechy charakterystyczne: Pomijanie sytuacji negatywnych w specyfikacji wymagań Brak informacji do testowania reakcji systemu na błędy lub na sytuacje wyjątkowe oraz do testowania przebiegów alternatywnych słabe testy Objawem jest uzgadnianie obsługi takich sytuacji pomiędzy programistami i testerami w zespole z pominięciem wymagań Powyższe błędy mają charakter procesowy. Wyjątki są mechanizmem na poziomie technicznym (implementacyjnym) wspierającym obsługę błędów. Stanowią więc istotny element oprogramowania, który w konsekwencji wspomnianych błędów procesowych jest niesłusznie niedoceniany.

4 Ze względu na niedocenianie znaczenia wyjątków rzadko są one prawidłowo projektowane. W szczególności zwykle trudno dopatrzeć się strategii, wg której zostały one zaprojektowane. Dlatego w czasie wykładu zostaną poruszone zagadnienia obejmujące: Dyskusję własności wyjątków własności te mają wpływ na sposób projektowania ich Omówienie strategii projektowania wyjątków

5 Wyjątki, jak sama nazwa wskazuje, służą do obsługiwania sytuacji wyjątkowych. W odróżnieniu od stosu wywołań metod, w którym wywołania metod odkładane są w kolejności ich wywołań, wyjątki propagowane są przez stos w kolejności odwrotnej. W zależności od języka programowania może je obsługiwać osobny stos, lub ten sam stos, który wykorzystywany jest dla wywołań metod. Klasy wyjątków zdefiniowane są w pakiecie biblioteki standardowej: java.lang UWAGA: wyjątki w Java są znane od dawna, jednak w Java 7 dodano try-with-resources, a w Java 8 wyrażenia lambda pozwalające efektywniej korzystać z try-with-resources. Wykład nawiązuje więc do Java 8.

6 Kiedy nie warto stosować wyjątków tylko wartość zwracaną (return): W czasie interakcji systemu z użytkownikiem Kiedy warto stosować wyjątki zamiast wartości zwracanych: Np. w warstwie danych Powód wyjątki mają przewagę nad obsługą błędów typową dla programowania strukturalnego wtedy gdy informacja o błędzie jest propagowana przez wiele metod i obsługa błędu jest rozproszona.

7 Miejsca powstania wyjątków: Kod biblioteki standardowej Java (np. operacje i/o wymagają obsługi wyjątków) Kod niestandardowej biblioteki obcej Własny kod Sposób powstania wyjątku jest jeden utworzenie obiektu klasy wyjątku (musi dziedziczyć ona z klasy Throwable) a następnie zgłoszenie wyjątku za pomocą słowa kluczowego throw. Przykład: throw new NumberFormatException("format liczby niezgodny z oczekiwanym: " + liczba);

8 Ogólna postać instrukcji sterującej zgłoszeniem wyjątku: throw exception_ref; gdzie exception_ref oznacza referencję do obiektu wyjątku. Zgłoszony wyjątek jest następnie propagowany w kierunku przeciwnym do kolejności wywołań metod na stosie. Jeśli nie zostanie przechwycony w kodzie, to będzie rozpropagowany do maszyny wirtualnej Javy (JVM), która zgłosi nieprzechwycenie wyjątku. Błędy polegające na nieprzechwyceniu wyjątku mają charakter błędów czasu wykonania (run-time), więc mogą być trudne do przewidzenia w czasie kodowania. Dlatego w Java wprowadzono dodatkowe mechanizmy na poziomie kompilacji ułatwiające wykrycie takich sytuacji na etapie kompilowania kodu zostaną one przedstawione dalej.

9 Zgłoszony wyjątek powinien zostać przechwycony i obsłużony. Do przechwycenia wyjątku służy klazula try-catch. Przykład: String s1, s2; try { int n1 = Integer.parseInt(s1); int n2 = Integer.parseInt(s2); catch (NumberFormatException exc) { System.out.println("Błędne dane - kończę działanie"); return;

10 Ogólna postać przechwycenia i obsługi wyjątku (wszystkie elementy z wyjątkiem jednego catch lub finally, jeśli wystąpiło try są opcjonalne): try { // instrukcje mogące zgłosić wyjątek catch(klasawyjątku1 ex) { // obsługa zidentyfikowanego wyjątku catch(klasawyjątku2 ex) { // obsługa zidentyfikowanego wyjątku catch(exception ex) { // obsługa niezidentyfikowanego wyjątku finally { // kod zostanie wykonany niezależnie od tego czy // wyjątek został zgłoszony czy nie i jakiej był klasy

11 Możliwości reakcji na przechwycenie wyjątku: Obsłużenie wyjątku i ponowne jego zgłoszenie Obsłużenie wyjątku i zgłoszenie innego wyjątku Obsłużenie wyjątku i niezgłaszanie żadnego wyjątku (kończy proces propagacji wyjątku) Wyjątki zachowują się jak obiekty (w istocie są nimi), w szczególności mogą zachowywać się polimorficznie. Tę ich własność wykorzystuje się w klauzulach catch, które mogą rozpoznawać klasę obiektu wyjątku po jej nadklasie. Można więc przechwycić wyjątek na podstawie jego nadklasy, a następnie dokonać analizy danych lub typu obiektu wyjątku i zareagować w zależności od zidentyfikowanych informacji. Podejście polimorficzne można też wykorzystać do sterowania przepływem wyjątków.

12 W celu zmniejszenia ryzyka nieprzechwycenia wyjątku, którego klasa w danej metodzie nie została przewidziana przez programistę (mogła nie istnieć w chwili pisania kodu przez niego) istnieje w języku Java możliwość przechwycenia wyjątku dowolnej klasy: catch(exception ex){ Istotne znaczenie w obsłudze wyjątków ma kolejność wystąpienia klauzul catch poniżej danego bloku try. Należy umieszczać je w kolejności od najbardziej szczegółowej klasy wyjątku do najbardziej ogólnej klasy wyjątku (szczegółowość w rozumieniu hierarchii dziedziczenia). Na samym końcu należy umieścić (opcjonalnie) klauzulę catch(exception ex). Dopiero po niej finally.

13 W języku Java wyjątki mają predefiniowaną hierarchię. Zawiera ona następujące istotne elementy: Error błędy, z którymi aplikacja nie jest w stanie sobie sama poradzić Exception nadklasa wyjątków, czyli błędów, z którymi aplikacja jest w stanie sobie poradzić RuntimeException klasa wyjątków niekontrolowanych InterruptedException klasa wyjątków kontrolowanych IOException klasa wyjątków kontrolowanych operacji we/wy

14 Wyjątki dzielą się na: Kontrolowane wymagają obsługi przez programistę dziedziczą z jednej z klas: InterruptedException IOException Niekontrolowane nie wymagają obsługi przez programistę dziedziczą z klasy RuntimeException Poza tym funkcjonalnie nie różnią się od siebie niczym.

15

16 Wyjątki predefiniowane (niektóre): IllegalArgumentException IllegalStateException NullPointerException IndexOutOfBoundsException ConcurrentModificationException UnsupportedOperationException Są one gotowe do wykorzystania przez programistów lub używane w bibliotekach standardowych. Predefiniowano wyjątki najczęściej spotykane.

17 Definiowanie własnej klasy wyjątku: class Wyjątek extends Exception { //...

18 W przypadku korzystania ze standardowej biblioteki języka Java, jeśli metoda z tej biblioteki może zgłosić wyjątek i nie obejmiemy w kodzie klienta tej biblioteki (naszym kodzie) blokiem try oraz klauzulą catch pozwalającą przechwycić ten wyjątek, to kompilator Java wykryje taką sytuację jako błąd. Możemy wtedy: Objąć wywołanie tej metody bibliotecznej blokiem try oraz zaimplementować klauzulę catch odpowiednią dla klasy nieprzechwytywanego wyjątku albo Dodać do nagłówka metody, w której został wykryty ten błąd (naszej metody) następującą deklarację: throws KlasaWyjątku1, KlasaWyjątku2,..., KlasaWyjątkuN

19 Dodanie powyższej deklaracji oznacza, że nasza metoda nie musi obsługiwać wyjątków tych typów, ponieważ może je zgłaszać (propagować dalej). Jeśli taką deklarację umieścimy w deklaracji naszej metody, to jej użytkownik będzie wiedział jakie wyjątki może zgłaszać nasza metoda. Przykład: public void method() throws NumberFormatException { // zgłoszenie wyjątku w method throw new NumberFormatException(); // albo // skorzystanie z metody, która może zgłosić wyjątek int i = convertstringtoint(new String( x ));

20 Klauzula finally wykonywana jest zawsze bezpośrednio po bloku try nawet wtedy, gdy obsługa wcześniej przechwyconego wyjątku w klauzuli catch zwróciła sterowanie z metody (słowo kluczowe return).

21 Możliwości uzupełnienia informacji o zagadnieniach związanych z wyjątkami: Exceptions anti-patterns informacje i przykłady ilustrujące jak nie należy korzystać z wyjątków Exceptions good practices zalecenia dotyczące korzystania z wyjątków; zbyt lakoniczne opisy mogą prowadzić do pochopnego wniosku, że niektóre praktyki są sprzeczne

22 Dobre praktyki obsługi wyjątków (wg. Lokesh Gupta): 1. Nigdy nie ignorować wyjątku w klauzuli catch 2. Zawsze deklarować wyjątki kontrolowane, które może zgłosić metoda 3. Nigdy nie przechwytywać wyjątku na podstawie jego nadklasy Exception 4. Nigdy nie przechwytywać wyjątku na podstawie jego nadklasy Throwable 5. Wychwycony wyjątek zawsze otaczać własną klasą w taki sposób, aby nie gubić śladu stosu 6. Albo logować informację o wyjątku albo go ponownie zgłaszać 7. Nigdy nie zgłaszać wyjątku z klauzuli finally 8. Wychwytywać tylko te wyjątki, które możemy obsłużyć

23 9. Nigdy nie pozostawiać w kodzie końcowym wywołań printstacktrace() 10.Używać klauzuli finally zamiast catch jeśli nie chcemy obsługiwać wyjątków 11.Przestrzegać zasady wczesnego zgłaszania i późnej obsługi wyjątku 12.Zawsze zwalniać zasoby po obsłużeniu wyjątku 13.Zgłaszać w metodzie wyjątek najbardziej odpowiedniej klasy 14.Nigdy nie używać mechanizmu wyjątków w sterowaniu przepływem programu 15.Walidować dane wejściowe w celu wczesnego zgłoszenia wyjątku 16.Zawsze logować pełną informację o każdym wyjątku 17.Umieszczać w wyjątku stosowne informacje w pełni go opisujące

24 18.Zawsze przerywać wątek, który zgłosił wyjątek 19.Stosować metodę szablonową zamiast powtarzania try-catch 20.Dokumentować wszystkie wyjątki w javadoc 21.Dla zwalniania zasobów należy preferować użycie finally w metodzie ponad użycie metody finalize w klasie

25 Konstruowanie własnej hierarchii wyjątków: Warto skonstruować własną nadklasę wyjątku dla biblioteki, żeby jej klient mógł przechwycić dowolny wyjątek z biblioteki w ramach pojedynczej klauzuli catch Zaleca się, aby hierarchie wyjątków były hierarchiami dziedziczenia, co jest sprzeczne z dobrymi praktykami inżynierii oprogramowania wzorce projektowe dla wyjątków?

26 Decyzja o tym czy wyjątki powinny być kontrolowane czy nie: Zaleca się spójność podejścia w odniesieniu do własnych wyjątków: albo wszystkie kontrolowane albo wszystkie niekontrolowane Czym kierować się w powyższej decyzji (argumenty za danym wyborem): Wyjątki kontrolowane Chcemy zaprząc kompilator do wspomagania procesu obsługi wyjątków Wyjątki niekontrolowane Nie chcemy zanieczyszczać kodu metod deklaracjami wyjątków Nie chcemy zanieczyszczać interfejsu deklaracjami wyjątków, które możemy chcieć zmienić w przyszłości

27 Wydaje się, że bardziej warte promowania są wyjątki niekontrolowane. Powody: Wyjątki niekontrolowane nie zanieczyszczają kodu zbędnymi blokami trycatch. Wyjątki niekontrolowane nie zanieczyszczają deklaracji metod zagregowanymi deklaracjami wyjątków. W praktyce rzadko zdarza się przeoczenie obsługi niekontrolowanego wyjątku. Powinny to wykryć testy, o ile proces wytwórczy jest prawidłowy. W praktyce nie potwierdza się opinia, jakoby trudniej było się zorientować jak obsłużyć wyjątek niekontrolowany. Wyjątki niekontrolowane pozwalają uniknąć problemu wersjonowania wymuszonego przez zmianę koncepcji obsługi wyjątków. Liczne dyskusje tego zagadnienia można znaleźć w internecie. Warto zauważyć, że C# wprowadza tylko wyjątki niekontrolowane nie bez powodu.

28 Obsługa wyjątków odporna na błędy. Może dojść do sytuacji, w której zgłoszenie wyjątku w bloku try może skutkować zgłoszeniem wyjątku w klauzuli catch i/lub w klauzuli finally. Przykład przerwania śladu pierwotnego wyjątku (por. z dobrymi praktykami).

29 InputStream input = null; try{ input = new FileInputStream( fname.txt"); //do something with the stream catch(ioexception e){ //first catch block throw new WrapperException(e); finally { try{ if(input!= null) input.close(); catch(ioexception e){ //second catch block throw new WrapperException(e);

30 Powyższy przykład ilustrujący utratę ciągłości śladu wyjątku nie jest skomplikowany. Dużo trudniejsze sytuacje obsługi wyjątków można spotkać w pracy z transakcjami JDBC. Aby zabezpieczyć się przed wspomnianym problemem należy zadbać o to, aby zawsze ostatni ze zgłoszonych wyjątków zawierał wszystkie zgłoszone wcześniej wyjątki. Ponadto w Java 7 wprowadzono mechanizm: try-with-resources Mechanizm ten pozwala rozwiązać wspomniany problem. Poprzedni przykład:

31 try(fileinputstream input = new FileInputStream( fname.txt")) { int data = input.read(); while(data!= -1){ System.out.print((char) data); data = input.read(); Dzięki temu, że FileInputStrem implementuje interfejs java.lang.autocloseable zasób ten zostanie automatycznie zamknięty po wykonaniu bloku try. W konstrukcji try-with-resources można wykorzystać każdą klasę, która implementuje ten interfejs. Mechanizm ten gwarantuje, że jeśli wyjątek zostanie zgłoszony w bloku try, to zostanie on rozpropagowany, podczas gdy wyjątek związany z zamknięciem zasobu zostanie wygaszony. Developer pozna więc pierwotną przyczynę zamiast problemów związanych ze sposobem obsługi błędu.

32 Jeśli trzeba obsłużyć w ten sposób więcej zasobów, to możemy wykorzystać konstrukcję: try( FileInputStream input = new FileInputStream( fname.txt"); BufferedInputStream bufferedinput = new BufferedInputStream(input) ){

33 Implementacja własnych zasobów podlegających mechanizmowi trywith-resources. Postać interfejsu AutoCloseable: public interface AutoClosable { public void close() throws Exception; Warto zauważyć, że jest to tzw. interfejs funkcyjny, co otwiera od razu możliwości zastosowania wyrażeń lambda z Java 8. Jest to zresztą obecnie dobra praktyka korzystania z zasobów.

34 Przykład własnego rozwiązania opartego o try-with-resources (źródło: Jakob Jenkov): public class MyAutoClosable implements AutoCloseable { public void doit() { System.out.println("MyAutoClosable doing public void close() throws Exception { System.out.println("MyAutoClosable closed!");

35 Przykład użycia własnej klasy implementującej AutoCloseable: private static void myautoclosable() throws Exception { try(myautoclosable myautoclosable = new MyAutoClosable()){ myautoclosable.doit(); Wynik wykonania powyższego kodu: MyAutoClosable doing it! MyAutoClosable closed!

36 Przykład wykorzystania rozwiązań z Java 8 dla Neo4J: wraz z zaznaczeniem zalet i wad takiego podejścia do obsługi wyjątków w transakcjach.

37 Problemem jest zanieczyszczenie kodu źródłowego (głównej logiki biznesowej, procesów biznesowych realizowanych w ramach paradygmatu klasowo-obiektowego) kodem obsługi wyjątków. Można to negatywne zjawisko ograniczyć na różne sposoby: Zastosowanie wzorca projektowego Metoda szablonowa mogącego prowadzić do obsługi wyjątków zbliżonej do sposobu obsługi zdarzeń Wzbogacanie wyjątków o informacje o unikalnym kodzie błędu i stosowanie exception handlers Zastosowanie podejścia aspektowego

38 Metoda szablonowa (źródło Jakob Jenkov). Mamy początkowo zanieczyszczony kod, który przy okazji pokazuje jak obsłużyć wcześniej rozważane problemy przerwania ciągłości wyjątków.

39 Input input = null; IOException processexception = null; try{ input = new FileInputStream(fileName); //...process input stream... catch (IOException e) { processexception = e; finally { if(input!= null){ try { input.close(); catch(ioexception e){ if(processexception!= null){ throw new MyException(processException, e, "Error message..." + filename); else { throw new MyException(e, "Error closing InputStream for file " + filename); if(processexception!= null){ throw new MyException(processException, "Error processing InputStream for file " + filename);

40 Dodajemy własną klasę zawierającą metodę szablonową stanowi ona implementację wspomnianego wzorca projektowego, z metodą o nazwie process() jako metodą szablonową, która jest parametryzowana kodem implementowanym przez klienta wzorca w metodzie doprocess().

41 public abstract class InputStreamProcessingTemplate { public void process(string filename){ IOException processexception = null; InputStream input = null; try{ input = new FileInputStream(fileName); doprocess(input); catch (IOException e) { processexception = e; finally { if(input!= null){ try { input.close(); catch(ioexception e){ if(processexception!= null){ throw new MyException(processException, e, "Error message..." + filename); else { throw new MyException(e, "Error closing InputStream for file " + filename); if(processexception!= null){ throw new MyException(processException, "Error processing InputStream for file " + filename); //override this method in a subclass, to process the stream public abstract void doprocess(inputstream input) throws IOException;

42 Warto zauważyć, że mamy do zaimplementowania jedną metodę korzystamy z anonimowej klasy wewnętrznej. new InputStreamProcessingTemplate(){ public void doprocess(inputstream input) throws IOException{ int inchar = input.read(); while(inchar!- -1){ //do something with the chars....process("somefile.txt"); Powyższy kod przypomina obsługę zdarzenia, jakim jest w tym przypadku zgłoszenie wyjątku.

43 Kolejny wariant wzorca wykorzystuje metodę statyczną nie trzeba tworzyć obiektu. Można również pokusić się o wykorzystanie interfejsów do implementacji tego wzorca lub wykorzystać wyrażenia lambda z Java 8 w implementacji z interfejsem mielibyśmy znowu interfejs funkcyjny.

44 Są znane dwie metody wzbogacania informacji związanej z kontekstem w zgłoszonym wyjątku (na podstawie: Jakob Jenkov): Exception wrapping Exception enrichment

45 Exception wrapping. Przykład: catch (SQLException sqlexception) { throw new MyException("error text", sqlexception); Zalety: Uniknięcie sytuacji, w której mamy ogólne metody z długą listą deklaracji niskopoziomowych wyjątków Zamiana niskopoziomowych wyjątków na bardziej ogólne na rzecz komponentów wyższych warstw Wady: Bardzo długi ślad na stosie wyjątków Sklejanie komunikatów o błędzie wewnątrz wyjątku trudne do dekompozycji i do zrozumienia przyczyny błędu

46 Exception enrichment. Polega na dodawaniu do obiektu wyjątku informacji kontekstowej i ponownym zgłaszaniu tego wyjątku. Przykład: try{ method1(); catch(enrichableexception e){ e.addinfo("an error occurred when trying to..."); throw e;

47 W ramach exception enrichment istnieje możliwość dodawania informacji o: Unikalnym kodzie błędu (identyfikujemy jednoznacznie rodzaj błędu znamy go w chwili zgłoszenia) Kontekście wystąpienia błędu (identyfikujemy miejsce w kodzie, w którym to miejscu wyjątek został zgłoszony)

48 Czasem nie da się uniknąć stosowania exception wrapping: Przechwycenie zarządzanego wyjątku non-enrichable exception catch(ioexception ioexception) throw new EnrichableException( ioexception, "METHOD1", "ERROR1", "Original error message"); Istnieje również możliwość wprowadzenia exceptions handlers jeśli wyjątki mają unikalne kody błędu. Wtedy można wyprowadzić ich obsługę spoza kodu procesu biznesowego.

49 W systemach korporacyjnych zwykle wymaga się logowania wyjątków. Umożliwia to analizowanie informacji o działaniu systemu przez pracowników przedsiębiorstwa korzystającego z takiego oprogramowania. Informacje takie mogą służyć: Analizie przyczyn problemu w oprogramowaniu Reprodukcji błędu pomocnej przy usuwaniu błędu W którym miejscu kodu powinno następować logowanie: Bottom-level logging logowanie od razu w komponencie, który zgłosił wyjątek Mid-level logging logowanie pośrodku stosu wywołań gdy wiedza o wyjątku będzie wystarczająca Top-level logging logowanie centralne na wierzchołku stosu wywołań

50 Bottom-level logging. Wady: Zakodowanie logowania w wielu miejscach na niskim poziomie Trudność z dostosowaniem sposobu logowania w przypadku wielokrotnego użycia komponentu w wielu aplikacjach Niedobór informacji w komponencie niskiego poziomu nie wiemy jakiej operacji znanej użytkownikowi dotyczył zgłoszony wyjątek

51 Mid-level logging Wady: Konieczność wzbogacania niskopoziomowej informacji Nadal dużo kodu obsługi błędów

52 Top-level logging Zalety: Wyraźny podział odpowiedzialności w systemie Jedno miejsce w kodzie do zarządzania obsługą błędów Wady: Brak wiedzy niskopoziomowej o przechwyconym wyjątku

53 W rozproszonych twardych systemach czasu rzeczywistego występują komponenty, których zadanie polega na obsłudze błędów lub zgłoszenia alarmów. Jest to więc podejście top-level. Dobrą praktyką jest wzbogacanie informacji o wyjątku w czasie wstecznej propagacji przez stos pod kątem logowania exception enrichment. Rekomendowana jest strategia top-level logging w powiązaniu z exception enrichment.

54 Strategia obsługi wyjątków (źródło Jakob Jenkov).

55 Wymagania dotyczące obsługi wyjątków: Pierwszorzędne (reakcja aplikacji, adresaci, diagnostyka) Drugorzędne (abstrakcja i enkapsulacja, łatwość wprowadzania zmian) Rodzaje błędów: Użytkownika Usług Wewnętrzne Klasyfikacja błędu może ulec weryfikacji podczas jego propagacji mamy wtedy do czynienia z jego re-klasyfikacją.

56 Elementy strategii obsługi wyjątków 1. Detekcja błędu 2. Zbieranie informacji o błędzie Przyczyna Lokalizacja 3. Zgłoszenie wyjątku 4. Propagacja wyjątku, możliwe wzbogacenie o informację kontekstową Pasywna Aktywna 5. Przechwycenie i reakcja na wyjątek: Powtórzenie operacji jeśli to możliwe Notyfikacja uczestników

57 Klasa wyjątku zawiera listę obiektów z informacjami o błędzie.

58 public class AppException extends Exception { protected List<ErrorInfo> errorinfolist = new ArrayList<ErrorInfo>(); public AppException() { public ErrorInfo addinfo(errorinfo info){ this.errorinfolist.add(info); return info; public ErrorInfo addinfo(){ ErrorInfo info = new ErrorInfo(); this.errorinfolist.add(info); return info; public List<ErrorInfo> geterrorinfolist() { return errorinfolist;

59 Klasa informacji o błędzie.

60 public class ErrorInfo { protected Throwable cause = null; protected String errorid = null; protected String contextid = null; protected int errortype = -1; protected int severity = -1; protected String usererrordescription = null; protected String errordescription = null; protected String errorcorrection = null; protected Map<String, Object> parameters = new HashMap<String, Object>();

61 Przykład użycia obu klas.

62 if(! new File(filePath).exists()){ AppException exception = new AppException(); ErrorInfo info = exception.addinfo(); info.seterrorid("filenotfound"); info.setcontextid("fileloader"); info.seterrortype(errorinfo.error_type_client); info.setseverity(errorinfo.severity_error); info.seterrordescription("no file found at file path + filepath); info.seterrorcorrection("filepath should point to existing file."); info.getparameters().put("filepath", filepath); throw exception;

63 W celu zmniejszenia ilości kodu odpowiadającego za tworzenie obiektów informacji o wyjątkach oraz za inicjalizowanie ich można skorzystać z fabryki (metoda wytwórcza) ErrorInfoFactory. Wtedy kod uprości się: try{ FileInputStream fileinputstream = new FileInputStream(filePath); //... catch (IOException e) { AppException exception = new AppException(); exception.addinfo( ErrorInfoFactory.getFileReadErrorInfo(e, filepath) ); throw exception;

64 Koniec