JDD09 Tomasz Skutnik PART4

### Overview W tej części prezentacji Tomasz Skutnik kontynuuje omawianie zaawansowanych aspektów obsługi błędów i wyjątków w aplikacjach Java, skupiając się na mechanizmach serwletów, spójności pamięci podręcznej i bazy danych, projektowaniu stron błędów oraz bezpiecznym zarządzaniu zasobami JDBC i JMS.

### Key Topics - **Model wyjątków w serwletach i filtry**: Domyślne wyłączenie filtrów podczas obsługi wyjątków (od wersji 1.4 możliwa deklaracja) oraz problem z utratą pierwotnej przyczyny błędu przy opakowywaniu w `ServletException`. - **Interakcja transakcji z pamięcią podręczną (Cache)**: Rozbieżności danych wynikające z wyczyszczenia i ponownego załadowania zmodyfikowanych danych do cache w trakcie transakcji, która kończy się błędem i wycofaniem (rollback). - **Projektowanie przyjaznych i użytecznych stron błędów**: Konieczność zachowania spójności graficznej, generowania unikalnych identyfikatorów błędów (np. 20 losowych znaków) korelowanych z logami oraz ułatwiania zgłoszeń (np. automatyczny JavaScript wysyłający raport). - **Obsługa JDBC i JMS oraz podwójne błędy**: Pułapki związane z zamykaniem zasobów (`ResultSet`, `Statement`, `Connection`), utrata pierwotnych wyjątków, brak domyślnego wypisywania `SQLState` i `SQL Error Code` przez `SQLException`. - **Biznesowe błędy i wyjątki od reguły szybkiego wywracania**: Wznawianie transakcji przy zakleszczeniach (deadlocks) oraz traktowanie naruszenia więzów integralności (np. unikalny login) jako normalnego przepływu biznesowego.

### Technical Details Prelegent omawia mechanizm obsługi wyjątków w serwletach, gdzie obsługa zachowuje się jak forward, lecz domyślnie wyłącza filtry, co bywa mylące dla programistów. Wskazuje również, że `ServletException.printStackTrace()` nie wypisuje stosu przyczyny (`root cause`), przez co generyczny kod musi jawnie wyłuskać pierwotny wyjątek.

W kontekście bazodanowym `SQLException` nie drukuje automatycznie kodów `SQLState` ani kodów błędów bazowych, co utrudnia diagnozę naruszenia ograniczeń integralności czy błędów składni. Prelegent przedstawia rozwiązanie oparte na klasie pomocniczej `JdbcUtil` oraz wzorcu funktora za pomocą interfejsu `ConnectionOp` (z implementacją np. `QueryOp` i metodą `invoke`). Metoda główna `withDataSourceConnection` odpowiada za pobranie połączenia, wykonanie operacji, a w sekcji `finally` za bezpieczne zamykanie `ResultSet`, `Statement` i `Connection`. Aby uniknąć zjawiska „podwójnego błędu” (gdy wyjątek podczas zamykania zasobu przesłania pierwotny błąd wykonania), stosuje się dedykowany wyjątek opakowujący, który zachowuje pierwotną przyczynę.

### Takeaways - Zawsze należy czyścić cache przy wycofywaniu transakcji (rollback), aby zapobiec serwowaniu nieaktualnych lub wycofanych danych. - Strony błędów powinny prezentować unikalny identyfikator błędu tożsamy z wpisem w logach serwera oraz jasno instruować użytkownika o charakterze awarii. - Zamykanie zasobów JDBC i JMS powinno być enkapsulowane w reużywalnych klasach narzędziowych chroniących przed podwójnymi błędami i utratą pierwotnych wyjątków. - Nie każdy błąd bazodanowy oznacza awarię krytyczną – sytuacje takie jak deadlocki mogą wymagać ponowienia transakcji, a naruszenia unikalności (np. równoległa rejestracja loginu) stanowią standardowy element logiki aplikacji.