O obsłudze sytuacji wyjątkowych słów kilka

Podczas jednej z niedawnych rozmów rekrutacyjnych (w sumie to chyba lubię na nie chodzić – często są dość inspirujące 🙂 ) spotkałem się z ciekawym pytaniem – „Jakie są negatywne konsekwencje stosowania konstrukcji try-catch?” Oczywiście zbyt wiele klawiatur zjadłem, by w ciemno walnąć głupotą, że są wyłącznie same zalety. Pominę co wtedy dokładnie odpowiedziałem, ale moja własna odpowiedź skłoniła mnie by jeszcze trochę pod tym kątem pogrzebać…

Trochę postów, trochę artykułów, sprawdzenie treści kilku książek. Wygląda na to, że ten teren nie jest jeszcze zbyt dokładnie spenetrowany… Mam swoją tezę do udowaodnienia – że jeśli już się decydujemy na przechwytywanie wyjątków to czeka nas ogromna ilość planowania i pracy. Tym artykułem postaram się ją udowodnić oraz podać kilka wskazówek jak można by zabrać się do realizacji tego zadania, o czym może warto pomyśleć z wyprzedzeniem.

Jednak na początek trochę rozważań teoretycznych i to zaczynając od poziomu bardziej abstrakcyjnego. Autor (Patrick Cauldwell) książki „Code Leader” (Amazon.com) dość jasno formułuje zasadę prezentowania sytuacji wyjątkowych użytkownikowi:

Errors should only be handed off to the user if there is something that the user can do to correct the problem, and that needs to be clearly communicated. (…) It is vitally important to make your error messages to the user actionable. If an error message doesn’t tell the user how to correct the problem, then there is no point in showing the user an error message.

Oczywiście po takim oświadczeniu natychmiast powinna nastąpić gorąca debata wśród architektów i programistów:

  • które błędy prezentować?
  • co robić z błędami których nie prezentujemy?
  • co zrobić z samą aplikacją po prezentacji błędu? Zwłaszcza z przetwarzanymi danymi?
  • które sytuacje to faktyczne wyjątki, a które to łatwe do przewidzenia sytuacje nieprawidłowości?
  • które błędy – ostatecznie – należy uznać za krytyczne i zagrażające porządkowi publicznemu?

Czytaj dalej O obsłudze sytuacji wyjątkowych słów kilka

Anonimizator – Nowy Projekt!

Cel projektu

Sytuacja wygląda tak – potrzebuję dostarczyć do zespołu deweloperskiego bazę produkcyjną aby dokonali na niej pewnych testów i optymalizacji. Występują też jeden czy dwa błędy, których nie daje się zreprodukować w środowisku testowym.

Oczywiście baza zawiera masę danych wrażliwych, które absolutnie nie powinny opuścić serwerów produkcyjnych. Zamazanie danych przypadkowymi śmieciami nie wchodzi w rachubę – rozkład statystyczny indeksów ulegnie zmianie i spora część pracy optymalizacyjnej deweloperów będzie bez sensu. Oczywistym jest, że w takim razie należy dane wrażliwe zastąpić danymi „niewrażliwymi” ale sensownymi, o w miarę naturalnym rozkładzie.

Dodatkowe wymagania

  • Dane w bazie są międzynarodowe – mają różną postać i niektóre także formaty
  • Warto zachować statystyczny rozkład danych
  • Powinna być otwarta na przyszłe formaty bazy – nowe bazy jak i rozbudowę / zmiany w istniejącej. Oraz nowe formaty danych.

Zarys rozwiązania

Swego czasu, podczas jednego z projektów, przygotowałem trochę klas generatorów danych testowych, takich jak dane osobowe, adresy, adresy e-mail. Dane bazowe dla generatorów były wyłącznie polskie a ponadto moduł adresów był potraktowany bardzo po macoszemu. Niewątpliwie jest to jakiś punkt wyjścia, ale zdecydowanie zbyt prymitywny na potrzeby funkcjonalnej anonimizacji. Głównie dlatego, że generatory generowały dane zupełnie przypadkowe (Do pewnego stopnia – np. nr PESEL i imię czy nazwisko były dostosowane do płci osoby, podobnie jak PESEL uwzględniał datę urodzenia osoby – o ile została dostarczona w przeciążonej metodzie.) a w obecnym przypadku musimy mieć możliwość kontroli nad zakresem zmian – np. rok i miesiąc urodzenia pozostają oryginalne a randomizujemy wyłącznie dzień albo losujemy imię o identycznej długości (chociaż to, może już nie spełniać wszystkich wymagań…).
Warto też by aplikacja dostarczała na tyle wygodny interfejs, by mogła z niego korzystać uprawniona osoba (Administrator Danych Osobowych), która prawie na pewno nie będzie programistą… Już na wstępie wydaje się zasadnym taki sposób przygotowania konfiguracji procesu, by rozdzielić opracowanie reguł od ich wykonania, oraz w pełni zabezpieczyć dane w bazie produkcyjnej przed niepowołanym dostępem ale także uchronić je przed celowymi lub przypadkowymi zmianami.

Literatura przedmiotu

  1. Niewątpliwie w pierwszej kolejności warto sięgnąć Ustawa o Ochronie Danych Osobowych.
  2. Ciekawym źródłem przydatnych wskazówek i wytycznych jest stosowna ustawa amerykańska dotycząca między innymi anonimizacji i deidentyfikacji pacjentów (HIPAA) wskazana na stronie Wikipedii – De-identification, i w interesującym zakresie dokładniej omówiona tutaj: Protected health information. Zamierzam dokładniej omówić ten ostatni artykuł w kolejnym poście, gdyż te wytyczne są bardzo istotne dla projektowania architektury systemu.