mysqli_report(MYSQLI_REPORT_OFF); $x = mysqli_query($polaczenie, 'SELECT * FROM mieszkancy'); if (!$x) echo "??????????????????????????????"; W...
mysqli_report(MYSQLI_REPORT_OFF); $x = mysqli_query($polaczenie, 'SELECT * FROM mieszkancy'); if (!$x) echo "??????????????????????????????";W przedstawionym kodzie PHP, zamiast znaków zapytania powinien pojawić się komunikat:
A. Zapytanie przetworzono pomyślnie.
B. Nieprawidłowa nazwa bazy danych.
C. Nieprawidłowe hasło do bazy danych.
D. Błąd przetwarzania zapytania.
Opracowane na podstawie zadania CKE, październik 2016 (arkusz E.14-X-16.08): W arkuszu użyto funkcji mysql_query, usuniętej w PHP 7. Zastąpiono ją mysqli_query; mysqli_report(MYSQLI_REPORT_OFF) sprawia, że błąd zapytania zwraca false.
Komunikat „Błąd przetwarzania zapytania.” pasuje tutaj najlepiej, bo warunek if (!$x) sprawdza, czy funkcja mysqli_query() zwróciła wartość fałszywą. W PHP przy zapytaniu SELECT funkcja mysqli_query($polaczenie, 'SELECT * FROM mieszkancy') powinna zwrócić obiekt wyniku, czyli mysqli_result, jeżeli zapytanie zostało poprawnie wykonane. Jeśli zapytanie się nie powiedzie, na przykład tabela mieszkancy nie istnieje, użytkownik bazy nie ma uprawnień do odczytu albo składnia SQL jest błędna, funkcja zwróci false. Wtedy negacja !$x daje true i wykonywany jest echo z komunikatem o błędzie przetwarzania zapytania.
Ważny szczegół: mysqli_report(MYSQLI_REPORT_OFF) wyłącza automatyczne raportowanie błędów przez mysqli, więc PHP nie rzuci wyjątku ani ostrzeżenia w standardowy sposób. Programista sam musi sprawdzić wynik i ewentualnie obsłużyć problem. Z mojego doświadczenia to jest klasyczny schemat w starszych zadaniach egzaminacyjnych: najpierw wykonanie zapytania, potem sprawdzenie, czy wynik istnieje. W praktyce produkcyjnej dobrze jest dodatkowo logować mysqli_error($polaczenie), ale użytkownikowi strony nie powinno się pokazywać surowych błędów SQL, bo to może ujawnić strukturę bazy danych. Dobra praktyka to komunikat ogólny dla użytkownika, a szczegóły tylko w logach serwera.
Ważny szczegół: mysqli_report(MYSQLI_REPORT_OFF) wyłącza automatyczne raportowanie błędów przez mysqli, więc PHP nie rzuci wyjątku ani ostrzeżenia w standardowy sposób. Programista sam musi sprawdzić wynik i ewentualnie obsłużyć problem. Z mojego doświadczenia to jest klasyczny schemat w starszych zadaniach egzaminacyjnych: najpierw wykonanie zapytania, potem sprawdzenie, czy wynik istnieje. W praktyce produkcyjnej dobrze jest dodatkowo logować mysqli_error($polaczenie), ale użytkownikowi strony nie powinno się pokazywać surowych błędów SQL, bo to może ujawnić strukturę bazy danych. Dobra praktyka to komunikat ogólny dla użytkownika, a szczegóły tylko w logach serwera.
W tym fragmencie kodu łatwo pomylić etap łączenia z bazą danych z etapem wykonywania zapytania SQL. Zmienna $polaczenie jest już używana jako gotowe połączenie, więc analizowany kod nie sprawdza tutaj ani nazwy bazy danych, ani hasła. Gdyby problem dotyczył nieprawidłowego hasła lub nazwy bazy, błąd pojawiłby się zwykle wcześniej, podczas wywołania mysqli_connect() albo przy wyborze bazy danych. Tutaj wykonywane jest konkretne zapytanie SELECT * FROM mieszkancy i dopiero jego wynik trafia do zmiennej $x.
Nie pasuje też komunikat „Zapytanie przetworzono pomyślnie”, ponieważ echo znajduje się wewnątrz warunku if (!$x). Operator ! oznacza negację logiczną, czyli kod w środku wykona się wtedy, gdy $x ma wartość false lub jest traktowane jak fałsz. Dla poprawnego SELECT-a mysqli_query() zwraca obiekt wyniku, więc warunek nie zostanie spełniony i żaden komunikat błędu nie powinien się pokazać. Moim zdaniem to właśnie ten wykrzyknik jest najczęstszą pułapką w takim pytaniu, bo ktoś widzi mysqli_query() i odruchowo myśli o sukcesie zapytania.
Warto też zauważyć, że mysqli_report(MYSQLI_REPORT_OFF) nie naprawia błędów i nie oznacza, że wszystko pójdzie dobrze. On tylko wyłącza automatyczne raportowanie błędów biblioteki mysqli. Dlatego odpowiedzialność za obsługę błędu spada na programistę. W dobrym kodzie po takim sprawdzeniu można zapisać techniczne szczegóły błędu do logu, np. informację z mysqli_error($polaczenie), ale na stronie dla użytkownika lepiej pokazać neutralny komunikat o problemie z przetwarzaniem zapytania. To bezpieczniejsze i bardziej profesjonalne podejście.
Nie pasuje też komunikat „Zapytanie przetworzono pomyślnie”, ponieważ echo znajduje się wewnątrz warunku if (!$x). Operator ! oznacza negację logiczną, czyli kod w środku wykona się wtedy, gdy $x ma wartość false lub jest traktowane jak fałsz. Dla poprawnego SELECT-a mysqli_query() zwraca obiekt wyniku, więc warunek nie zostanie spełniony i żaden komunikat błędu nie powinien się pokazać. Moim zdaniem to właśnie ten wykrzyknik jest najczęstszą pułapką w takim pytaniu, bo ktoś widzi mysqli_query() i odruchowo myśli o sukcesie zapytania.
Warto też zauważyć, że mysqli_report(MYSQLI_REPORT_OFF) nie naprawia błędów i nie oznacza, że wszystko pójdzie dobrze. On tylko wyłącza automatyczne raportowanie błędów biblioteki mysqli. Dlatego odpowiedzialność za obsługę błędu spada na programistę. W dobrym kodzie po takim sprawdzeniu można zapisać techniczne szczegóły błędu do logu, np. informację z mysqli_error($polaczenie), ale na stronie dla użytkownika lepiej pokazać neutralny komunikat o problemie z przetwarzaniem zapytania. To bezpieczniejsze i bardziej profesjonalne podejście.