Android: w jaki sposób powinienem obsługiwać wyjątki dostępu DB?

Question

Moje pytanie dotyczy dobrych praktyk w zakresie obsługi wyjątków DB.

Powiedzmy, że mam aplikację, która przechowuje pewne dane w DB. Wdrażane są następujące warstwy:

1. DatabaseAdapter - zajmuje się zapytaniami SQL i dostarcza dane do wyższej warstwy w postaci modelu. Adapter zawiera metody, takie jak:
   • getAllUsers list()
   • void adduser (UserModel użytkownik)
2. UserListActivity - pokazuje listę wszystkich użytkowników, pozwala na dodanie nowego użytkownika itd. Aktywność ta wykorzystuje DatabaseAdapter do odczytu/zapisu bazy danych.

Pytanie brzmi: czy powinienem obsłużyć wyjątek dotyczący dostępu do bazy danych, na przykład podczas dodawania nowego rekordu (zakładając, że rekord powinien zawsze być poprawnie dodany)? Czy mam po prostu spróbować przechwycić wyjątek w DatabaseAdapter i dodać go do dziennika? A może w ogóle nie powinienem tego złapać?

Answer 1

W większości przypadków wyjątek podczas wysyłania zapytań do bazy danych jest wynikiem błędu "czasu rozwoju", takiego jak nieprawidłowe zapytanie lub modyfikacji schematu, ale nie zwiększa wersji bazy danych lub czegoś podobnego. Będzie można je łatwo znaleźć i naprawić bezpośrednio na miejscu, więc użytkownicy końcowi nie będą mieli do czynienia z takimi błędami.

Jednakże istnieją także realne możliwości, które mogą mieć wyjątków w następujących przypadkach:

• spróbować uzyskać dostęp do bazy danych SQLite z wielu procesów (przepis na katastrofę).
• Użytkownikowi zabraknie miejsca na dysku na swoim urządzeniu.
• Masz nieprawidłowo sformułowane zapytanie z powodu nieprawidłowego wprowadzania danych wejściowych użytkownika.
• Istnieje błąd w metodzie onUpgrade() lub coś podobnego.
• Używasz integralności referencyjnej (możliwe w SQLite 3.6.19 i wyższej) i niektóre ograniczenia tabeli nie.

Naprawdę, nie ma uniwersalnej odpowiedzi na te scenariusze. Dla użytkownika końcowego pokazanie prostego błędu jest o wiele lepsze, niż na przykład zamknięcie aplikacji.

Moja zasada polega na tym, aby za wszelką cenę uniknąć uszkodzenia bazy danych. Wolałbym raczej rzucić RuntimeException i natychmiast zabić aplikację, a nie po cichu zrobić coś złego. Ponadto wolałbym wyświetlać komunikat mówiący, że nie można ukończyć wstawiania, a nie wymuszać zamykanie aplikacji.

Answer 2

Nie ma wspólnej odpowiedzi na to pytanie, która pasuje zawsze. Zależy to od przypadku użycia. Dwie reguły obowiązują zawsze: nie przesyłaj zbyt szczegółowych komunikatów o wyjątkach do powyższej warstwy (interfejs użytkownika nie musi znać problemu w składni SQL) i obsługuj wyjątek tam, gdzie ma to sens (nie pokaż okno dialogowe błędu w twojej klasie DB). Można na przykład przechwycić wyjątek bazy danych w klasie DB, zarejestrować go, a następnie ponownie wygenerować niestandardowy wyjątek CustomerNotFoundException, który zostanie przechwycony w interfejsie użytkownika, w którym można wyświetlić okno dialogowe błędu.