Jak obsługiwać znane bugi?

0

Pracuję nad aplikacją w PHP która ma działać na każdej wersji od 5.6 w górę. Jednym z elementów tej aplikacji jest łapanie błędów przy regexach (php'owe funkcje preg_match(), preg_replace(), etc...). Do pewnego czasu istniał bug w php, który sparawiał że niektóre błędy regex'owe nie sprawiały że preg_last_error() zwracał kod błędu - czyli mimo że był błąd, to i tak preg_last_error() == PREG_NO_ERROR.

W PHP 7.1.13 poprawili ten bug, tutaj: https://bugs.php.net/bug.php?id=74183

No właśnie, i teraz testy uruchomione na PHP <7.1.12 działają (bo aplikacja którą testują wie o tym bugu), a jeśli uruchomić testy na PHP +7.1.13 to już nie przechodzą. Ponieważ aplikacja myśli że stało się coś złego - preg_last_error() przestało zwracać PREG_NO_ERROR.

Noi pytanie co teraz, mam dwa pomysły:

  • Albo napisać dwie wersje testów, po jednym na wersje pre-bugfix oraz post-bugfix
  • Albo starać się naprawić buga pre 7.1.12, i mimo że preg_last_error() zwraca PREG_NO_ERROR (kiedy nie powinno), jakoś próbować wymyślić co by zwróciło już po bugfixie? Tutaj trzeba by pisać jakąś logikę zgadującą błąd.
3
  1. Napisać prosty wrapper, który będzie 'ogarniał' ten błąd. Tzn. zamiast preg_match robiłbyś np. Regex::match, gdzie to Regex::match byłoby pewną fasadą na domyślnie PHPowe wyrażenia regularne, udostępniającą jednolity interfejs.
0
Patryk27 napisał(a):
  1. Napisać prosty wrapper, który będzie 'ogarniał' ten błąd. Tzn. zamiast preg_match robiłbyś np. Regex::match, gdzie to Regex::match byłoby pewną fasadą na domyślnie PHPowe wyrażenia regularne, udostępniającą jednolity interfejs.

Noi skąd ta fasada wiedziałaby jaki error poleciał?

PS: "ogarniał" to znaczy co? Zachowywał się tak jak przed bug'fixem? To znaczy nawet jak preg_last_error() zwróciy dobry błąd, to i tak wyciszyć na PREG_NO_ERROR?

0

Ach - myślałem, że jest jakiś inny sposób na dowiedzenie się o tym błędzie (jakaś inna funkcja, rezultat preg_match itd.) - jeśli nie ma, no to podejście odpada.

0
Patryk27 napisał(a):

Ach - myślałem, że jest jakiś inny sposób na dowiedzenie się o tym błędzie (jakaś inna funkcja, rezultat preg_match itd.) - jeśli nie ma, no to podejście odpada.

z preg_match() można się dowiedzieć tylko bool'a :D Czy był błąd czy nie był. Jaki konkretnie błąd można tylko z preg_last_error(), tylko niestety (przed 7.1.12) nie w każdym case'ie.

0

A nie można w tym przypadku, na czas testu, sięgnąć po regexa w innym języku (np. perl) lub w zewnętrznym toolu, który nie ma takiego problemu?

0
TurkucPodjadek napisał(a):

A nie można w tym przypadku, na czas testu, sięgnąć po regexa w innym języku (np. perl) lub w zewnętrznym toolu, który nie ma takiego problemu?

Nie

0

Musiał byś po swojemu napisać wykrycie tego błędu, zależy co to dokładnie jest. Możesz podać ten przykład dokładniej, chociażby linka do tego buga?

0

Ok, zrobiłem dwa testy jednen na przed 7.1.12, a drugi 7.1.13+. Na odpowiednich wersjach odpowiednie testy są skippowane. Nie wiem czy to dobre podejście.

0

ja bym zaszył podobnie jak to zasugerował @Patryk27i wewnątrz Regex::match dałbym sprawdzanie wersji PHP. Wtedy masz tylko jeden test a i w produkcyjnym kodzie unikniesz wielokrotniego sprawdzania tego buga.

0
no_solution_found napisał(a):

ja bym zaszył podobnie jak to zasugerował @Patryk27i wewnątrz Regex::match dałbym sprawdzanie wersji PHP. Wtedy masz tylko jeden test a i w produkcyjnym kodzie unikniesz wielokrotniego sprawdzania tego buga.

No ale skąd w poprzednich wersjach będzie wiedział jaki był error code, skoro przed bugiem ta metoda zawsze zwraca PREG_NO_ERROR?

0

@no_solution_found: Chyba nie kumasz o co chodzi z problemem. Dobrze, mogę zrobić

class Regex
    public static function getError($subject) {
        if (PHP_VERSION_ID >= 70113) {
            return preg_last_error();  // na php 7.1.13 i wyżej zwróci np PREG_BAD_UTF8
        }
        return // niby co mam tutaj zwrócić, skoro dla <7.1.13 zwraca zawsze PREG_NO_ERROR - skąd będę wiedział jak exception był.
    }
}

1 użytkowników online, w tym zalogowanych: 0, gości: 1