[Yanushevitz]

czy w MVC, event-driven architecture ma sens przy tworzeniu error handlingu? Załóżmy że za każdym razem gdy rzucony jest jakikolwiek błąd, łapię go i tworzę event, a event listener zwraca response z odpowiednią odpowiedzią, że wystąpił błąd. Refaktoryzuję swój stary kod API i zastanawiam się jak taki system zaimplementować żeby było miło. Zastanawia mnie tylko, skoro kontrolery są odpowiedzialne za zwracanie response, jak przekierować tam później ruch z listenera. Ewentualnie zrobić tak, żeby listener samodzielnie zwrócił response, tylko czy to nie zaburzyłoby sensu wzorca MVC?
#programowanie #php #symfony

[lojawyk]

@Yanushevitz: Nie musisz nigdzie przekierowywać ruchu z powrotem do kontroler. Masz w symfony wszystkie potrzebne eventy, żeby zrobić to praktycznie bez typowych kontrolerów.

Jeśli oprzesz wszystko na eventach to będziesz miał ładną kontrolę od wejścia do wyjścia eventami jak w API Platform.
Sprawdź właśnie API Platform, bo tam wszystko leci na eventach.

[MrDracek]

@Yanushevitz: ciekawa koncepcja, ale osobiście bym olał robienie listenera, którego głównym celem już jest przygotować konkretny response pod konkretny endpoint - na takiej zasadzie, że one już przygotowują w teorii konkretnego typu response, pod konkretny już Content-Type.

Mogę się mylić, ale tak mi powiedzmy obecnie logika podpowiada.

Ogólnie jeszcze dam inny przykład: Laravel. Laravel wymyślił coś takiego jak error-handler, opakowujący kontrolera w (bardzo upraszczając) w try-catcha. Kiedy wystąpi konkretny exception

[mariecziek]

@Yanushevitz: U mnie w robocie zrobiliśmy podobnie jak chyba jest to w Larvie, bo przyszli programiści Larvy i namieszali nam w symfony hehe.
Kontrollery zawsze kod mają opakowany w try... catch. Jeżeli zostanie rzucony jakikolwiek wyjątek - zwrócony będzie po prostu kod 500 i wiadomość z wyjątku, ale można sobie w kontrollerze dodać tablicę z wyjątkami - jeśli zostanie złapany wyjątek z tablicy wyjątków - można ustawić inny kod błędu