Wprowadzenie
Każdy programista pisze kod, który działa – do czasu, aż pojawi się błąd. Wtedy zaczyna się prawdziwy test architektury. Obsługa błędów (error handling) to jeden z najbardziej niedocenianych aspektów backendu, a jego koszty są często ukryte głęboko w budżetach operacyjnych. Złe podejście do błędów nie tylko frustruje użytkowników, ale generuje realne straty: wyższe rachunki za chmurę, spadek konwersji i dług techniczny. W tym artykule przyjrzymy się trzem powszechnym błędom, które widzę w projektach małych i średnich firm.
Błąd 1: Łapanie wyjątków w złym miejscu
Objawy
Widok w logach pełen błędów Error: something went wrong. Zespół developerów spędza godziny na próbach odtworzenia problemów. Klienci zgłaszają, że strona nagle przestaje działać, a CTO nie wie, co się stało. To klasyczny objaw łapania wyjątków na zbyt niskim poziomie lub zbyt wysokim – bez kontekstu.
Dlaczego to boli biznes
Załóżmy, że Twój e-commerce ma endpoint zamówienia. Gdzieś w głębi logiki biznesowej kod rzuca wyjątkiem, gdy magazyn nie ma wystarczającej ilości towaru. Jeśli złapiesz go w kontrolerze i zwrócisz 500 Internal Server Error, użytkownik zobaczy ogólny komunikat – i zrezygnuje z zakupu. Ale jeśli złapiesz go zbyt nisko, np. w warstwie dostępu do danych, możesz ukryć problem, który powinien być widoczny (np. brak połączenia z bazą). To prowadzi do utraty zamówień i trudniejszej diagnostyki.
Rozwiązanie
Stosuj architekturę warstwową z dedykowanymi klasami błędów. Na przykład: rzucaj OutOfStockError w logice biznesowej, a w kontrolerze łap go i zwróć odpowiedni kod HTTP (np. 409 Conflict) z komunikatem „Produkt niedostępny”. Inne błędy, jak DatabaseConnectionError, powinny być logowane i zwracać 503. Dzięki temu frontend może odpowiednio zareagować, a Ty wiesz, co się dzieje.
Błąd 2: Zbyt szczegółowe komunikaty błędów w API
Objawy
Endpoint API zwraca { "error": "Invalid email format: [email protected]" } lub gorzej – { "error": "SQL error: Column 'email' cannot be null" }. To częsty widok w aplikacjach, które nie odfiltrowują informacji o wewnętrznej strukturze.
Dlaczego to boli biznes
Po pierwsze, bezpieczeństwo: wyciek szczegółów bazy danych lub struktury kodu ułatwia ataki. Po drugie, UX: nie każdy błąd musi być widoczny dla użytkownika. Jeśli podasz zbyt techniczny komunikat, użytkownik – zwłaszcza w B2B – może stracić zaufanie. A jeśli Ty jako właściciel produktu widzisz w logach dokładny zapytanie SQL, to narażasz się na wyciek danych wrażliwych.
Rozwiązanie
Zadbaj o warstwę translacji błędów. Dla klienta zwracaj zrozumiałe komunikaty (np. „Nieprawidłowy format adresu email”). Tymczasem pełny stack trace i szczegóły techniczne loguj do systemu monitorowania (np. Sentry, Datadog) z odpowiednim poziomem dostępu. Unikaj używania generycznego { "error": true } – to też frustruje.
Błąd 3: Brak obserwowalności błędów
Objawy
Zespół dowiaduje się o błędzie od klienta. Nikt nie sprawdza logów regularnie. Gdy pojawia się problem, trzeba spędzić godziny na ręcznym przeglądaniu plików.
Dlaczego to boli biznes
Brak monitorowania błędów to prosta droga do utraty klientów i pieniędzy. W przypadku SaaS czy e-commerce każda minuta przestoju kosztuje. Bez alertów o błędach krytycznych (np. 5xx, timeouty) reagujesz z opóźnieniem. Dodatkowo, bez agregacji błędów trudno dostrzec trendy – np. że w weekendy rośnie liczba błędów związanych z płatnościami.
Rozwiązanie
Wdróż narzędzia do monitorowania błędów (Sentry, Rollbar, New Relic) skonfiguruj alerty o błędach krytycznych. Zasada: każdy błąd 5xx powinien być natychmiast zgłoszony. Dla błędów biznesowych (np. płatność odrzucona) ustaw alerty z mniejszym priorytetem, ale regularnie je przeglądaj. Dodatkowo loguj metryki: czas odpowiedzi, liczbę błędów na endpoint, statusy HTTP. To pozwoli Ci szybko wykryć problemy.
Podsumowanie
Error handling to nie tylko kwestia techniczna – to element strategii biznesowej. Dobrze zaprojektowana obsługa błędów oszczędza czas, pieniądze i buduje zaufanie. Złe podejście generuje ukryte koszty: więcej czasu na debugowanie, utracone zamówienia, wyższe rachunki za chmurę (bo błędy obciążają CPU i pamięć) oraz spadek morale zespołu.
Przyjrzyj się swoim logom. Czy widzisz tam komunikaty, które nic nie mówią? Czy Twoje API wycieka szczegóły implementacji? Czy w ogóle wiesz, ile błędów występuje dziennie? Jeśli odpowiedź na któreś pytanie brzmi „nie”, to znak, że warto zainwestować w porządną obsługę błędów. Jako praktyk, który zajmuje się tym na co dzień, widzę, jak wiele firm traci pieniądze przez pomijanie tego obszaru. A przecież naprawa jest prosta – wystarczy kilka poprawek w kodzie i dobre narzędzia.
