PHP - Fractal of bad design (2024)

W świecie PHP brak istotnych zmian. Hipotetyczne dokumenty księgowe wystawiane 30 lutego wpisują się (niestety) w smutny kanon.

Jest to ciekawy i dość poważny błąd standardowej biblioteki funkcji języka, ponieważ może pozostać niezauważony. Nieistniejąca (nieprawidłowa) data jest bowiem wewnętrznie korygowana bez przerwania przetwarzania błędem lub wyjątkiem. Język zgłasza błąd dopiero wtedy, gdy spróbujemy ustawić dzień powyżej 31.

Równie problematyczny jest brak wyjątków, czyli do tej pory w PHP został zachowany status quo, tj. niespójny error handling (parse error, recoverable error, fatal error, exceptions):

<?php

$date = '2024-02-30';

try {
    $dateTime = new DateTime($date);
    echo "Data jest dobra!\n";
} catch (ex) {
    echo "Zła data: $date ($ex)";
}

$newDate = $dateTime->format('Y-m-d');

echo $newDate;

W efekcie dla 2024-02-30 otrzymamy:

Data jest dobra!
2024-03-01

a dla 2024-02-32 blok try-catch nie zadziała:

Fatal error: Uncaught Exception: Failed to parse time string (2024-02-32) at position 9 (2): Unexpected character in /home/user/scripts/code.php:6
Stack trace:
#0 /home/user/scripts/code.php(6): DateTime->__construct('2024-02-32')
#1 {main}
  thrown in /home/user/scripts/code.php on line 6

W Pythonie daty obsługiwane są prawidłowo:

import datetime
datetime.date(2024, 2,30)

w efekcie wygeneruje:

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [4], in <cell line: 1>()
----> 1 datetime.date(2024, 2,30)
ValueError: day is out of range for month

Wyjątek ValueError można przechwycić jak każdy inny wyjątek.

Z tego typu powodów w moim warsztacie nie uwzględniam PHP jako narzędzia nadającego się do profesjonalnych rozwiązań.

• Php